Comprobar si existe y recibir id o insertar

[terit]

Buenas a todos, espero que me podáis echar una mano


tengo 40 tablas de "caracteristicas" y una general que necesita de estas 40

La estructura sería asi:

Código:

Tabla Color
id  nombre
1 Negro
2 Azul
...

Tabla Tamaño
id nombre  
1 100
2 105
...

Asi hasta 40 tablas distintas, luego tengo la general con este formato:

Código:

Tabla `zapatos` (42 campos)

Id Color Tamaño Material etc...
1    2          24         6

Tengo un formulario con 40 campos de texto donde la visita escribe directamente los 20 tipos de caracteristicas (verde,300,piel, etc)

Una vez enviado el post debo de hacer 40 selects individuales para conocer si el valor escrito ya existe en la base de datos, si si existe me guardo el id y si no, hago un Insert y me guardo el id, una vez hecho esto creo la fila en la tabla "zapatos" con los 40 ids obtenidos.

Esta manera me parece, a mi modo de ver, muy ineficiente ya que son 41 consultas distintas, si esto lo multiplicamos por 400 0 500 clientes simultáneos puede ser una carga grandisima... se os ocurre alguna manera mas eficiente de hacerlo?


Saludos !

[gnzsoloyo]

Lo que tienes es un espanto de diseño de base.
¿Por qué no empiezas explicando cómo es el sistema y qué se supone que ingresan en ese formulario? Sería más sencillo para aconsejarte si tenemos una idea clara de lo que estás administrando.

[terit]

No entiendo muy bien que necesitas y no tengo ninguno problema en dar todos los detalles necesarios pero no pasaría nada si emplearas un poco más de tacto....


En cuanto a la parte del formulario es relativamente irrelevante, el formulario me dá 40 variables de texto ($color=azul, $tamaño=100, etc), con estas 40 variables debo crear una fila en `zapatos` con los 40 correspondientes ID de cada tabla de caracteristicas, para conocer los ID primero debo hacer un select en la tabla "color" para saber si Azul existe y recibir el ID de Azul (en el ejemplo q puse antes, sería el 2) , tb debo hacer otro en la tabla tamaño, y asi sucesivamente en las 40 tablas, igualmente debo crear el nuevo valor si no existiera

[gnzsoloyo]

Mira, lo que te pregunto es la descripción general del sistema que desarrollas en ese form (que si es relevante), porque da la impresión, a priori, que hubieses atomizado una sola entidad "Zapato", separando cada atributos de la misma en diferentes tablas.
Al menos eso es lo que se infiere de la existencia de tablas como Color, Tamaño, Material, etc.
Si realmente has separado cada atributo de la entidad "Zapato" en esas tablas, tu sistema adolece de un exagerado nivel de normalización, al punto que resula ineficiente.
Por eso digo que tienes un espanto de base. ¿Se entiende?
Una de las preguntas que siempre surge en la clase de Bases de Datos II, es ¿hasta qué punto se debe llevar na normalización? Y la respuesta que te dan los profesores es: hasta donde el sistema sea eficiente, y a mi entender el tuyo no lo es.
El problema que tiene generar un exceso de normalización es que requiere de consultas demasiado complicadas para reconstruir una sola instancia de la entidad representada... como termina siendo también tu caso.
A menos que me equivoque en la inferencia, ese es el problema que te enfrentas: Las consultas para obtener los datos que quieres requieren una sintaxis innecesariamente compleja.

Por eso es que te pido que expliques mejor cómo es lo que debes modelar, para ver si lo que tienes es correcto para lograr la información que quieres.

[terit]

Muy buenas, efectivamente mi sistema es tal como dices

Te explico el por que de tanta normalizacion y me comentas que opinas

Por un lado necesito separar los atributos (color, tamaños, etc) en distintas tablas ya que en el formulario hay un sistema ajax que sugiere resultados (por ejemplo en Color si escribo "A" me va a sugerir Amarillo, azul, etc) Entiendo que asi es mucho mas eficiente la consulta que irme directamente a una supuesta tabla general "Zapato" con 40 campos varchar, buscar solo donde color="$color", recorrer muchas mas registros y con mas campos, omitir los duplicados, etc...

Por otro lado necesito de esta normalizacion ya que por ejemplo, tengo 2500 registros en la tabla Zapatos donde el campo Color es "2" (Azul), con solo hacer un update a la tabla Color al ID 2 y cambiar "Azul" por "Azul claro" , esos 2500 zapatos son ahora Azul claro

Tambien tengo entendido que es mucho mas eficiente enfrentarse a una tabla con campos mediumint que varchar a la hora de hacer estadisticas (cuantos zapatos azul tengo por ejemplo) , es esto cierto?

Dime que me sugieres

[Ribon]

Pero es cierto también que hay campos que separarlos en tablas distintas es completamente "desaconsejado" (por no usar otra palabra xD), por ejemplo el tamaño, para que quieres que se sugiera un tamaño? si es un número, distinto sería si el tamaño fuera textual, ya sea "grande" "pequeño" "mediano", los números como sugerencia desde mi punto de vista es una perdida de tiempo, para ver los tamaños dale el trabajo a la validación que es donde tienes que verificar que el tamaño sea correcto, no la base de datos.

y eso solo con la tabla tamaño que fue una de las que pusiste de ejemplo, puedo estar seguro que si listas acá las 40 y pico tablas de tu sistemas varias desaparecerían y serían absorbidas como atributo dentro de tu tabla zapato.

Saludos.

[terit]

Iniciado por Ribon

Pero es cierto también que hay campos que separarlos en tablas distintas es completamente "desaconsejado" (por no usar otra palabra xD), por ejemplo el tamaño, para que quieres que se sugiera un tamaño? si es un número, distinto sería si el tamaño fuera textual, ya sea "grande" "pequeño" "mediano", los números como sugerencia desde mi punto de vista es una perdida de tiempo, para ver los tamaños dale el trabajo a la validación que es donde tienes que verificar que el tamaño sea correcto, no la base de datos.

y eso solo con la tabla tamaño que fue una de las que pusiste de ejemplo, puedo estar seguro que si listas acá las 40 y pico tablas de tu sistemas varias desaparecerían y serían absorbidas como atributo dentro de tu tabla zapato.

Saludos.

Tienes razón en lo que comentas pero en mi caso todas las tablas son texto, he puesto el ejemplo de 100, 200.. pero también las hay 100SP 200 mini etc..., realmente no hay ninguna característica que sea siempre un número

[Ribon]

Sería bueno pusieses el listado de tablas, no me imagino 40 caracteristicas distintas en un zapato xD!

a ver si así vemos que se puede denormalizar.

saludos

[terit]

jeje Realmente no es un Zapato, pero es un ejemplo mucho mejor de entender, en realidad son piezas de una maquina industrial con nombres muy raros, en general hay una media de 2500 tipos por cada tabla (más las que salen cada mes)

[gnzsoloyo]

Bueno, eso ya es algo mucho mejor, y me sirve para aclararte una cosa que a veces los que recién se incian en los foros de consulta no tienen claro: No es buena idea usar modelos imaginarios por"similitud" para hacer preguntas, porque en bases de datos los esquemas no son generalizables en la mayoía de los casos.
Planear un modelado de base para zapatos tiene muchísima menos complejidad que una abse de datos para piezas de máquinas-herramienta, como dices ahora. Se trata de universos de representación completamente diferentes y que nos habla de esquemas de categorización ealmente complejos.
No hay forma de que te hubiésemos podido dar una solución sobre la base del ejemplo que planeaste originalmente. Con este, la cosa cambia, pero necesitamos un poco más de claridad en cuanto a qué nivel de jerarquizaciones existenen las categorías, y si es posible que determinados componentes sean dependientes de otros, o formen parte de ellos.
Este tipo de datos nos permite ver si existe la posibilidad de resolver las consultas en forma de subconsultas jerárquicas, y si (como infiero) sería mejor plantear stored procedures para la mayor parte de las validaciones.
Al menos eso es lo que yo veo.

[terit]

Gracias por las respuestas

En cuanto las validaciones si te refieres a validar datos (si cumple requisitos y demas) todo eso se encarga el código php de forma que siempre se inserta texto saneado y cumpliendo los requisitos en la base de datos

En cuanto a la relación, no he comentado esto por no complicar mi pregunta y tratar de molestar lo minimo posible pero realmente de esos 40 campos, 20 son de marcas y 20 de modelos ,

digamos ...

Código:

Marca_pieza1 |       Modelo_pieza1

Id  nombre      |  Id      Nombre          idmarca
1   Bosh           |  1     Valvula FT            1      
2   Dacy           |  2     Valvula FT             2

El motivo de tener que insertar los 40 valores y no 20 (solo modelo y luego buscar marca segun modelo) es por que como podéis ver, hay piezas que se llaman exactamente igual pero son de distinta marca, por eso en la tabla general debo de insertar tanto el id de modelo como el id de marca.

Ninguno de los modelos tienen relación entre si, digamos que son "extras" independientes, cualquiera de las 20 piezas pueden ser cualquiera sin dependencias entre si, si te refieres a que si el tipo de pieza1 es XX el tipo de pieza2 no puede ser YY , esto no existe en mis necesidades, como ya te digo, son totalmente independientes , las unicas relaciones son marca1 y pieza_tipo1, marca2 pieza_tipo2 etc...

Saludos

[Ribon]

Tiene 20 piezas y las pones como campo?
no sería mejor hacerlo así?



http://i44.tinypic.com/287ezae.png

Saludos

[terit]

Perdona pero no te entiendo muy bien o quizá me he expresado mal y no me has entendido bien

Tengo 20 tipos de piezas que a su vez tienen 1500 modelos cada tipo y que a su vez cada pieza puede ser de una marca (+ de 3000 )


La manera que tu propones sería en meter las 30mil (20 *1500) piezas en una única tabla llamada Pieza ?

Saludos

[Ribon]

Cada pieza tiene un modelo y una marca

Esa tabla almacenaría la relación entre ese modelo y marca que conforma una pieza, por ejemplo

Pieza = "cordón"
Marca = 3 => "Mistic"
Modelo = 5 => "AR567"

y a la vez ese cordón está en una máquina.

las cardinalidades quedarían

Una máquina puede tener muchas piezas
un pieza tiene un modelo y una marca
La misma marca pueden tenerla múltiples piezas
y Un modelo puede ser adoptado por muchas piezas.

[terit]

Iniciado por Ribon

Cada pieza tiene un modelo y una marca

Esa tabla almacenaría la relación entre ese modelo y marca que conforma una pieza, por ejemplo

Pieza = "cordón"
Marca = 3 => "Mistic"
Modelo = 5 => "AR567"

y a la vez ese cordón está en una máquina.

las cardinalidades quedarían

Una máquina puede tener muchas piezas
un pieza tiene un modelo y una marca
La misma marca pueden tenerla múltiples piezas
y Un modelo puede ser adoptado por muchas piezas.

Me parece perfecto lo que me dices, estoy mirando ahora mismo más acerca de los "relationships" y lo voy a hacer tal como tu dices, entonces si contamos con que la estructura es tal que así, como deberia ser ese insert/select de los 40 campos para que fuera lo mas eficiente posible?

Saludos

Edito:

Me refiero a la hora de recibir (y validar) las 40 variables desde el formulario del cliente

PD: Recordar que un modelo no puede repetirse si pertenece a la misma marca y pieza

[Ribon]

Para recibir todas las piezas con sus respectivos marcas y modelos para una máquina

Código MySQL:

SELECT p.nombre_pieza , md.nombre_modelo, mc.nombre_marca
FROM
pieza p
JOIN marca mc ON mc.id_marca = p.id_marca
JOIN modelo md ON md.id_modelo = p.id_modelo
WHERE p.id_maquina = 1
 

ahí obtendras todas las piezas de una máquina con sus respectivas marcas y modelos de la siguiente manera


http://i42.tinypic.com/4pxsgo.png

----

Para recibirlas del formulario podrías ponerles nombres del tipo

name="marca[]"
name="modelo[]"
name="pieza[]"

así lo obtendrías como array (en PHP)

y ahora para traer los datos para el "autocompletado" solo vas a buscar a la tabla de marcas las marcas, a la tabla de modelos los modelos, etc.

saludos

[terit]

Gracias por tu colaboración, me sirve de mucho todo lo que has puesto pero me referia a la pregunta inicial, los inserts, ya que el formulario más que para otra cosa está para insertar nuevos modelos y marcas , algunos formularios se rellenaran totalmente con nueva información que no contiene la base de datos de marcas y modelos, otros solo con algunas... por lo tanto siempre debo mirar primero si existen y sino, insertarlos ...

Entiendo que no me queda otra que hacer 40 selects y XX inserts (dependiendo de las cosas que existen o no)


Edito:

Parece que te he entendido mal y no he sido capaz de explicarte que no solo hay 1 maquina, sino tantas como formularios se hagan, cada vez que un usuario envia el formulario crea una maquina nueva compuesta de 20 piezas, por lo tanto este resultado:

debería ser asi:

[Ribon]

Claro, por eso mio ejemplo decía "Piezas para la maquina con id = 1"
Tienes que plantearte las otras consultas para las otras máquinas
o hacer join con la tabla de máquinas y agrupar en tu programación.

saludos.

[terit]

Muy buenas!

Sería esta estructura correcta?

El campo "TIPO" de la tabla "modelos" será un campo del 1 al 20 que indica el numero de pieza, que simplemente utilizado para estadísticas (que modelo es el mas usado en la pieza tipo=3 por ejemplo)

La tabla "Maquinas" solo lleva 2 campos por abreviar, realmente serían 20 (id_modelo_pieza1 - id_modelo_pieza20)



http://i44.tinypic.com/rlw7q9.jpg

Saludos

[Ribon]

Si una pieza puede estar en muchas máquinas y una máquina puede tener muchas piezas entonces el modelo que te presenté yo sería el correcto.

Porque en caso de que una máquina pase a tener 21 piezas vas a tener que entrar a modificar la estructura de la tabla, y como habrán máquinas que no tendrán 21 piezas estarás violando la 1ra forma normal de normalización, una tabla no debe tener campos nulos.

Saludos.

[terit]

Si no me equivoco, esta sería la estructura que tu propones:



http://i41.tinypic.com/sqikvn.jpg

[Ribon]

Puedes corregir las cardinalidades?, tengo una duda.

Una misma pieza puede estar en muchas máquinas?

Saludos.

[terit]

Si, una misma pieza o incluso una misma pieza del mismo modelo y marca pueden estar en 1000 maquinas, de hecho solo hay 20 tipos de pieza y estará en todas las maquinas, lo único q cambiaran son los modelos y las marcas, pero siempre serán las mismas 20 piezas (he cambiado a tu formato por aquello de en un futuro ampliar a 22,24 piezas o las que surjan)

Para que lo entiendas mejor, uno de los 20 tipos de pieza puede ser un Neumático, otra el volante, y las maquinas serían un coche, siempre van a tener neumáticos y volantes, solo q unos tendrían una marca y otros otra

[Ribon]

Bien, entonces el tipo de pieza es una clasificación de esta o podríamos llamarlo una "generalización" de una pieza.

debido a que una misma pieza (mismo modelo y marca) puede estar en distintas maquinas y en una máquina muchas piezas, entonces supongo que este modelo satisface a todo eso.



http://i44.tinypic.com/23mo5fb.png

Teniendo en tipo_pieza registros como "neumático", "volante", etc
además las piezas son una conjunción de marcas, modelos y tipo de pieza y posee su id único debido a que forma parte de otra tabla (relación explicita), pieza_maquina que contiene los id de las máquinas y las piezas que poseen.

no se que más normalizado podría estar pero a mi parecer este modelo satisface a todos los requerimientos =)

saludos.

[Ribon]

Por cierto, lo que aún no me queda claro es si un mismo modelo puede estar en distintas piezas, en caso de ser así la tabla modelo desaparecería y pasaría a ser un atributo en la tabla pieza modelo varchar (XX)

me cuentas como te fue

saludos.

[terit]

Iniciado por Ribon

Por cierto, lo que aún no me queda claro es si un mismo modelo puede estar en distintas piezas, en caso de ser así la tabla modelo desaparecería y pasaría a ser un atributo en la tabla pieza modelo varchar (XX)

me cuentas como te fue

saludos.

Exacto, al final realmente he quitado la tabla modelos

Estoy haciendo pruebas ahora mismo insertando formularios y en el peor de los casos (rellanar los 40 campos) tarda unos 3-4 segundos en realizarlas. (recordar que se hacer 40 inserts independientes)

Estoy utilizando wamp en windows, confío que en un servidor vaya mejor...

[Ribon]

Recién me di cuenta que escribí mal lo de los modelos xD!
al menos si entendiste xD!

Eso de 40 inserts independientes se podría mejorar con prepared statements?

Suerte =)

Saludos

[terit]

No conocía esa instrucción, la probaré..

En cualquier caso, por si a alguien le sirve

Cada insert tarda unos 0.12 segundos en producirse (0.12 * 40 = 4.8segundos)

Me he dado cuenta que es mas eficientes hacer dos SELECT (uno a modelos y otro a marcas) para comprobar si existen los 40 modelos (0.050s *2) , y luego 2 inserts con multiples values (0.12s * 2) y luego otros dos SELECT para recibir los ids de los nuevos registros insertados (0.050s *2)

En la teoría esto me da un tiempo máximo de 0.450 segundos que no está nada mal , aun que entiendo que conforme las tablas tengan mas registros tardára mas en hacer los 4 SELECT

Saludos