Cita:
Iniciado por jpinedo Yo no estoy de acurdo con ese nivel pues se perdería mucho sentido semántico de los campos. Y te planteo una duda :¿Qué tipo de dato le pondrías al campo 'valor'?.
En eso tienes razón, pero hay casos en los que eso no tiene mucha importancia y es una opción a valorar.
Esta propuesta ya la he visto implementada y yo mismo la he implementado en algún caso.
¿Tipo que le pones?: evidentemente tiene que ser un char/varchar, no puedes poner otra cosa por la variabilidad de los datos que puede contener. Está claro que esta forma no se puede implementar siempre, pues pierdes funcionalidades según el tipo de datos (fechas, números, sobre todo). Pero en un caso en lo que sólo metes datos descriptivos sobre los que no vas a hacer más operaciones, que tienes mucha variabilidad en el número de datos y/o muchas características no obligatorias, esta forma de ponerlo es totalmente válida.
También he implementado la otra forma, con las tablas adicionales por tipo de elemento, pero tiene el problema que por cada tipo de elemento nuevo que añades, tienes que crear una nueva tabla.
Por último, también he implementado una única tabla con todas las características de todos los tipos de elementos. Hay que pensar que hablamos de una tabla maestra y el espacio desprovechado es mínimo, salvo que tengas miles de registros en esta tabla.
Para mi la decisión de que forma implementar, siempre que me encuentro este problema, viene dada por el uso que se le van a dar a los datos a más. Y, personalmente, no me gusta estar sujeto a que a alguien, después de un tiempo se le ocurra que se le ha quedado un tipo de elemento en el tintero y por culpa de eso tener que andar tocando el código, que es lo que sucedería con las tablas a mayores por cada tipo de elemento.
Un saludo.