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

Question

Estoy tratando de crear una base de datos que contenga una lista de equipos. Todos los equipos tendrán ciertos atributos comunes (como fabricante, número de modelo, número de serie, etc.), luego hay otros atributos que son específicos de un determinado equipo (es decir, un módem tendrá un número de acceso, mientras que un panel solar tendrá una capacidad de salida). No estoy seguro de cómo representar estos atributos cambiantes con buenos principios de diseño de bases de datos, he intentado buscar en la web, pero no estoy seguro de qué buscar.

que he llegado con las siguientes soluciones posibles y mis reflexiones iniciales sobre ellos:

1. Tiene una gran mesa con todos los atributos posibles y sólo hay que poner nula donde no es aplicable. Obviamente esto tiene algunos defectos.

2. Tenga una tabla separada para cada tipo de equipo. Parece que puede ser una pesadilla usar, si quiero imprimir una lista de todos los equipos, ¿cómo sé qué tablas buscar?

3. Tenga una tabla con los atributos comunes, y otras tablas para cada tipo de equipo al que se accede con una clave externa para almacenar los atributos adicionales. Probablemente podría hacer que esto funcione, pero sería engorroso y simplemente no parece una muy buena solución.

4. Modelo de tipo entidad-valor-atributo. Simplemente no parece una muy buena opción para lo que quiero hacer.

no tengo mucha experiencia con bases de datos, así que estoy aprendiendo sobre la marcha aquí, los enlaces relacionados con este problema o "lectura obligatoria" artículos sobre diseño de base de datos sería apreciada. ¡Gracias!

EDITAR: En primer lugar, descubrí que necesitaba Google "Mapeo de herencia", que podría ayudar a cualquier otra persona que tenga una pregunta similar. Para resolver el problema terminé usando un híbrido de # 2 y # 3. En realidad fue bastante fácil, funciona bien y resuelve el problema de agregar tipos de equipos adicionales sin la complejidad de EAV. Gracias por todos los comentarios y sugerencias!

Answer 1

Las opciones 1, 2 y 3 comparten una falla muy grave: tiene que 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 está arreglado para siempre?¿Qué tan feliz será de tomar interrupciones o decirle al cliente que no, no puede tener un nuevo atributo?

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

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.

Answer 2

Es un problema difícil de resolver para cualquier base de datos SQL. No hay una gran respuesta para MySQL.

1) Funciona y puede agregar algunas vistas para tipos de equipos importantes. Reduce el número se une y permite consultas e índices en cada campo.

2) Puede utilizar una consulta de todos los sindicatos a la vista. PostgreSQL e Informix tienen herencia de tablas.

3) Esta es frecuentemente una opción de implementación. Nuevamente, puede usar vistas para las uniones.

4) PostgreSQL, Informix, Oracle, IBM DB2 y MS SQL Server tienen un soporte de tipo de datos XML para implementar los pares de valores.

En un nivel superior, puede desarrollar un metamodelo del equipo en XML. Luego puede usar este modelo para generar consultas SQL de esquema y código CRUD.

Answer 3

Creo que enfrenta una normalización de base de datos regular. Es necesario mesas como:

Items -> Id, Name, Model, Brand Id 
Brands -> Id, Name 
Attribute Names -> id, name 
Attribute Mappings -> Id, Names Id, Items Id, Attribute Description 

En caso de que si hay más de un attribué, a continuación, en la lista de tablas de atributos y asociarse con Id de producto, etc. Trate de llegar a tercera forma normalizada

Database Normalization

Answer 4

Las alternativas 1, 2 y 3 son descritas por Martin Fowler en uno de sus libros y en su sitio web.

Single Table Inheritance (option 1)

Concrete Table Inheritance (option 2, sort of)

Class Table inheritance (option 3)

Mi preferencia es la opción 3. Cada uno tiene su lugar en el esquema general de las cosas.

EAV se adapta muy bien añadiendo nuevos atributos sobre la marcha. Pero cuando llega el momento de convertir los datos en información útil, una base de datos EAV puede ser una pesadilla.

Tengo una respuesta más larga, que publicaré a pedido.