sql >> Base de Datos >  >> RDS >> Mysql

Buen diseño de base de datos, número variable de atributos

Las opciones 1, 2 y 3 comparten un defecto muy grave:debe modificar el esquema de la tabla subyacente cuando alguien sueña con un nuevo atributo. En el caso de la Opción 1, el problema se ve agravado por la posibilidad de que se introduzca un nuevo tipo de equipo. ¿Qué tan seguro está de que el conjunto de atributos es fijo para siempre? ¿Qué tan feliz estará si realiza interrupciones o le dice al cliente que no, que no puede tener un nuevo atributo?

Si es muy probable que realice consultas sobre atributos comunes, puede probar un híbrido de 3 y 4, con una pizca de 2 en la división del tipo de atributo en lugar del tipo de equipo, que parece mucho más volátil. La opción 4, si entiendo correctamente, es una versión de forma normal de la opción 1 que resuelve todos sus problemas inherentes (escasa y frágil).

INVENTORY( id*, model, manufacturer, serial )
ATTRIBUTE( id*, name, type, description )
INVENTORY_FACT_STRING( inv_id*, attr_id*, value )
INVENTORY_FACT_NUMBER( inv_id*, attr_id*, value )
INVENTORY_FACT_LIST_STRING( inv_id*, attr_id*, ordinal*, value )

etc.