Un problemilla de diseño

[un_tio]

Tengo en principio una base de datos en la que tiene que figurar esto:

distintos "tipos" de elementos. Así por ejemplo, si estamos hablando del inventario de un coche, y tengo distintos coches, quiero que haya una tabla para cada tipo de elemento de coche (por ejemplo, una tabla para los neumáticos, otra tabla para los volantes, etc. (cada una incluye características, tales como la marca, el precio, etc.)).

Y además, por supuesto, quiero que uno de los atributos de cada tabla (de la tabla "neumático", de la tabla "volante", etc.), sea el coche en el que está (en un Honda, en un Volkswagen...).

Así pues, puedo hacer una de dos cosas:

-O cada tabla de tipo de elemento unida directamente a la tabla de coche.
-O cada tabla de tipo de elemento unida a otra tabla, donde se unen a coche. En este caso, las id's de los tipos de elementos vendrían en esta segunda tabla, y las demás tendrían que coincidir con ésta.

La segunda forma sería una forma de organizar en "subclases".

¿Qué me recomendáis? ¿Cómo puedo luego reconocer qué tablas pertenecen a inventario (pues en la base de datos habrá tablas de clientes, etc.)? ¿Puedo poner de nombre a las tablas "inventario_nombretabla" y luego buscar las tablas que comiencen por inventario_?

[ludovico2000]

Creo que lo mejor sería:

[VOLANTES]
<código>
<marca>
<...>

[RUEDAS]
<código>
<marca>
<...>

[COCHES]
<...>
<volante>
<rueda>

Y la relación sería

[COCHES]
<...>
<volante>-----[VOLANTES]<código>
<rueda>------------------------------[RUEDAS]<código>

De esta forma, en la tabla coches tienes un registro "Ford Mondeo" que tiene un volante "FORD0101-A" que en la tabla de volantes corresponde a un volante ford color ocre y el coche tiene rueda "FORD0203-J" que en la tabla ruedas corresponde a una rueda ford especial para nieve.

Y podrás crear consultas tipo "Qué coches llevan qué volantes/ruedas", "Qué volantes/ruedas llevan cierto tipo de coches" etc.

espero haberte ayudado

[un_tio]

Hmmm... ¿Las claves primarias de rueda y volante son distintas? Supongo que sí.

Otra cosa: tú has metido el campo "tipo de elemento" dentro de la tabla coches. ¿No sería mejor meter el id del coche como un campo dentro de cada tabla de elementos de coche? Los problemas que veo de no hacerlo así son estos dos:

-Un coche lleva dos tipos de rueda (que las traseras, o la delantera sea de otra marca. Da igual, el caso es considerar que haya algún elemento, el que sea, que puede estar repetido y de distintas marcas).

-Surgen nuevos tipos de elementos (por ejemplo, la radio, que hipotéticamente no la hubieras definido en la tabla de coches, o un invento nuevo como un "filtro para el tubo de escape"): será más fácil que al crear la tabla del nuevo elemento, simplemente añadamos la id del coche a cada elemento que en la nueva tabla incluyamos (con un campo reservado para el coche), a crear un nuevo campo en la tabla coche.

[Vice]

Yo la tabla coches la definiría de otra forma:
coches: idcoche, idelemento, tipoelemento, ...
De esta forma guardas una fila por cada elemento que forme parte de un coche. Si salen nuevos tipos de elementos o varios elementos de un tipo, no te dará problema.
Un saludo.

[un_tio]

Ya. O sea, tú propones hacer que cada elemento tenga una especie de clave única formada por su id de su tabla más el nombre del tipo de elemento. Pero esta clave no tendría sentido en su tabla de origen, donde con poner la id bastaría... ¿propones que en la tabla coche, en "tipo de elemento", poner el nombre de la tabla (que será el tipo de elemento)?
Por supuesto, entiendo que hablas de id's autonuméricas separadas, no compartidas, entre los distintos tipos de elementos.

¿Y qué tal el meter en la tabla del elemento la id del coche, en lugar de al contrario?

[Vice]

Es que yo no hubiera separado los elementos por tablas, sino que hubiera hecho una tabla de elementos con un campo tipo/categoría del elemento.
Si lo que guardas son elementos genéricos, sin serialización, no puedes poner el dato en la tabla de elementos, porque ruedas las tienen todos los vehículos, ¿qué haces entonces para que dos coches tengan ruedas?.
Pero claro, todo esto te lo digo sin conocer que es lo que se quiere hacer exactamente.

[un_tio]

No, no, es que cada rueda es única, sí que es con "serialización".

Y sí que había que separar los elementos por categorías, pues cada uno de ellos llevan asociados distinto número de campos distintos (por ejemplo, quizás las ruedas tengan un parámetro que sea "dureza", otro "desgaste", etc., que no tengan los volantes).

[Vice]

¿Pero no estás mezclando características genéricas de un tipo de elemento con el elemento en si mismo?.
Me explico: la dureza, características especiales, grado de desgaste, ..., va asociado a una rueda de marca X, tipo M. Pero todas las ruedas de la marca X, tipo M, tienen esas mismas características.
A lo que llegamos: es mejor una tabla maestra de elementos tipo: ruedas, volantes, asientos, puertas, ... donde estén los datos que los caracterízan y después otra tabla con la serialización. En esta segunda tabla si se podría hacer como dices.
Pero haciendo una tabla por tipo de elemento, para encontrar todos los elementos de un coche te tendrás que recorrér n tablas. Sinceramente, creo que esta forma de diseñarlo te complicará la programación sobremanera, por no decir el mantenimiento de las tablas.
En cuanto a las características adicionales para los elementos, se puede hacer de dos formas:
1. tablas adicionales para las características adicionales. (tablas: ruedasplus, volantesplus, ...)
2. un tabla donde se meta una fila por cada característica adicional. Tabla: elementosplus: idelemento, caracteristica, valor.

Personalmente me gusta más la segunda, pues siempre tienes una única forma de ir a buscar las características adicionales y no andar buscando a que tabla ir a buscar las cosas en función de que elemento estemos hablando.

Mmm, espero que se entienda la idea.
Un saludo.

[un_tio]

Si haces una tabla de elementos tipo con sus características desperdiciarás mucha memoria, puesto que cada uno tiene distinto número de campos y dejarás campos vacíos.

Es decir, te lo diré con un ejemplo de qué podría pasar de hacerlo así:

Tipo de elemento-----Característica1---Característica2---Característica3

Volante---------------Radio de giro------Electrónica-----------Cuero (sí/no)
Freno--------------------ABS--------------"Nada"----------------"Nada"


¿Me he explicado? Esos son los problemas de meter todos en la misma tabla.

Al final lo que haré será quizás, como has dicho, hacer una tabla de elementos, pero sin poner atributos, sólo para poner los nombres de los tipos de elementos que hay. Y luego, una tabla por cada tipo de elemento, donde aparezcan ya serializados y con todas sus características: así, la tabla genérica de "tipos de elementos" serviría para buscar al resto de tablas.

Lo que se me ocurrió, para ahorrar dicha tabla, era lo de los nombres de las tablas: "inventario_volantes, inventario_frenos": ¿me explico? Si las tablas llevan un "código" delante, introducido en el título, igual para todas, como "inventario", es fácil consultar qué tablas tienes con un select (el mismo que harías sobre la tabla tipo de elementos si hicieras esta).

[Vice]

Si van a tener características distintas puedes hacer una segunda tabla donde se metan las características de los tipos de elemento, no como campos, sino como filas, de esta manera tienes tantas filas por tipo de elemento como características tenga.
ejemplo:
(idelemento, característica, valor)
volante --- radio de giro --- x
--- electronica --- x
--- cuero --- Si

freno --- abs --- Si

Lo normal en estos casos es hacer una tabla con los campos comunes a todos ellos, aquellos que siempre van a tener datos y una tabla auxiliar donde se meten los extras.
Si lo metes en la tabla de serialización, inducirás a un error peor que si lo pones en la maestra, por que si bien en la maestra pierdes parte del tamaño de una fila, en la de serialización serán n filas con datos, una por cada número de serie.
Y lo que dices de hacer varias tablas, siempre tendrás un número indeterminado de tablas a cruzar cuando quieras obtener los datos y, cuando tengas que añadir un nueto tipo de elemento, tendrás que crear una nueva tabla.

Un saludo.

[un_tio]

Lo primero, gracias por la ayuda, Vice.

Iniciado por Vice

Si van a tener características distintas puedes hacer una segunda tabla donde se metan las características de los tipos de elemento, no como campos, sino como filas, de esta manera tienes tantas filas por tipo de elemento como características tenga.
ejemplo:

(idelemento, característica, valor)
volante --- radio de giro --- x
--- electronica --- x
--- cuero --- Si

freno --- abs --- Si

Una dudilla sobre el diagrama: en sql, en una tabla, no puede repetirse el campo de la clave primaria. Es decir, que dos filas no podrían contener a la palabra volante. ¿No hay clave primaria?

Puede que estés en lo cierto pero aún no lo veo claro.

Iniciado por Vice

Lo normal en estos casos es hacer una tabla con los campos comunes a todos ellos, aquellos que siempre van a tener datos y una tabla auxiliar donde se meten los extras.
Si lo metes en la tabla de serialización, inducirás a un error peor que si lo pones en la maestra, por que si bien en la maestra pierdes parte del tamaño de una fila, en la de serialización serán n filas con datos, una por cada número de serie.

Vale, entonces propones hacer una tabla con los campos comunes, y una auxiliar con los extras (que todavía no he entendido bien cómo dices de hacerla).

¿La serialización cómo iría?

Entiendo que tú propones hacer una tabla de "tipos de elemento", con las características específicas en otra tabla. Y después, para la serialización (que es importante para decir la localización de cada elemento, por ejemplo: "está en el garaje tal", por ejemplo), llamar a un campo que sea "tipo de elemento", pues suponemos que lo van a compartir todos los elementos de ese tipo, sea cual sea su número de serie.

Iniciado por Vice

Y lo que dices de hacer varias tablas, siempre tendrás un número indeterminado de tablas a cruzar cuando quieras obtener los datos y, cuando tengas que añadir un nueto tipo de elemento, tendrás que crear una nueva tabla.

Un saludo.

Efectivamente, así lo iba a hacer. ¿Qué problema ves en que haya un número indeterminado de tablas, si se puede obtener? ¿Y en tener que crear una nueva tabla para cada tipo de elemento?

Saludos

[Vice]

La clave primaria en esa tabla no sería el idelemento sólo, sino el idelemento+característica.

El problema de crear una nueva tabla por cada tipo de elemente, es que vas a tener que modificar todas tus consultas para obtener los datos. Cada nuevo tipo de elemento que hagas te modifica la forma de obtener los datos, pues es una nueva tabla a tener en cuenta.
Ten en cuenta que estás simplifcando mucho: te quedas con volante, ruedas, ..., pero la cantidad de tipos diferentes es demasiado grande como para que se haga sostenible un sistema como el que propones. Proponte obtener un listado de uso de los elementos y verás como se te complica las cosas.

Una cosa que tienes que hacer es diferenciar tablas maestras de tablas históricas o de trabajo. En tu caso, defines una (o un par) de tablas maestras donde se ponen los datos que definen a los elementos:
tipo_elementos (idelemento, nombreelemento, cararc1, carac2, ...), primary=idelemento
tipo_elementos_plus (idelemento, caracteristica, valor),primary=idelemento, caracteristica
vehiculos: (idvehiculo, idelemento, numserie, ...), primary=idvehiculo, idelemento
(te puedes plantear el usar una tabla maestra de características)
Con las dos primeras tablas defines los componenetes que vas a usar, en la segunda defines la composición de los vehículos, serializando los componentes que lo forman.