No, este es un mal diseño para una base de datos relacional. Este es un ejemplo del Entity-Attribute-Value diseño. Es flexible, pero rompe la mayoría de las reglas de lo que significa ser una base de datos relacional.
Antes de descender al diseño de EAV como una solución para una base de datos flexible, lea esta historia:CaRMa malo .
Más específicamente, algunos de los problemas con EAV incluyen:
- No sabe qué atributos existen para un ID_NUM determinado sin consultarlos.
- No puede hacer que ningún atributo sea obligatorio, el equivalente de NOT NULL.
- No puede usar restricciones de base de datos.
- No puede usar tipos de datos SQL; el
valuela columna debe ser un VARCHAR largo. - Particularmente en MySQL, cada VARCHAR se almacena en su propia página de datos, por lo que esto es un gran desperdicio.
Las consultas también son increíblemente complejas cuando utiliza el diseño EAV. Magento, una plataforma de comercio electrónico de código abierto, utiliza ampliamente EAV y muchos usuarios dicen que es muy lento y difícil de consultar si necesita informes personalizados.
Para ser relacional, debe almacenar cada atributo diferente en su propia columna, con su propio nombre y un tipo de datos apropiado.
He escrito más sobre EAV en mi presentación Practical Object-Oriented Modelos en SQL y en mi publicación de blog EAV FAIL , y en mi libro, Antipatrones SQL:Cómo evitar las trampas de la programación de bases de datos .
