diseño de base de datos: flexibilidad frente a la simplicidad

Question

Estoy tratando de sopesar las ventajas y desventajas relativas de una estructura de base de datos simple como esto:

1.

CREATE TABLE x (
    my_id INT PRIMARY KEY, 
    ..., 
    text_attribute_blah TEXT, 
    text_attribute_blah_blah TEXT 
); 

vs:

2.

CREATE TABLE x (
    my_id INT PRIMARY KEY, 
    ... 
) 

CREATE TABLE attributes (
    my_id INT, /* foreign key to x.my_id */ 
    text_attribute_type INT, 
    text_attribute TEXT 
) 

Donde attribute_type podría ser blah o blah_blah.

La opción 1 ofrece simplicidad: la tabla es más fácil de leer/escribir; La opción 2 ofrece flexibilidad (si queremos agregar otro atributo como blah_blah_blah, no necesitamos hacer cambios de esquema y, por lo tanto, probablemente menos cambios de código).

¿Hay una respuesta correcta/incorrecta para este enigma? ¿Una de estas opciones se considera una mejor práctica que las demás? ¿Puede indicarme una lectura adicional que podría ayudar a determinar el camino a seguir?

Answer 1

Casi siempre elegiría el n. ° 1: prefiero tener atributos como columnas en mis tablas: hace que las consultas, la indización de rendimiento y el manejo general sean mucho más fáciles y transparentes.

el # 2 opción se llama EAV - Entidad Atributo Valor - y tiene algunos inconvenientes importantes - ver

• Five simple database design errors you should avoid - el enfoque EAV es # 3 en la lista
• Joe Celko: Avoiding the EAV of destruction

Answer 2

Opción 1 casi todas las veces. La opción 2 es muy ineficiente. También es bastante torpe consultar fácilmente cuando tienes que hacer algo con más eficiencia. Una vez dicho esto, he visto una serie de productos que hacen esto para los atributos definidos por el usuario. Los ejemplos de sistemas que utilizan la técnica de la opción 2 son Agresso y Kalido.

Si está realizando una aplicación a medida, la mejor manera de agregar atributos es ampliar el esquema de la base de datos cuando sea necesario. Como el cambio irá acompañado de modificaciones en el código, se puede hacer como parte del proceso de lanzamiento.

Si está haciendo una aplicación empaquetada que tiene la intención de que los clientes se configuren, tiene tres enfoques amplios que puede tomar.

1. estructura EAV como la opción 2. Esto es flexible, pero es ineficaz para consultar, en particular en las consultas consiguen complejo con varias combinaciones.

2. Crea un conjunto de campos 'Usuario' (Usuario1, Usuario2, etc.) en las tablas. Esto te limita a un número finito, pero puede ser bastante grande (podrías tener User01-User99 si lo deseas). Sin embargo, es la más eficiente y simple de consultar. La otra desventaja es que los campos son algo opacos. Debe tener acceso a la información de configuración para conocer el significado de 'Usuario3'. También sacrifica algún tipo de seguridad. En resumen, sin embargo, su mecanismo de campo de usuario va a tener algunos de sus propios metadatos y un marco genérico de algún tipo, por lo que se puede proporcionar algo de ese tipo de seguridad a través de esto.
   
   Esto parece el más poco elegante, pero es la mejor manera de hacerlo en la mayoría de los casos, ya que tiene el mejor rendimiento y las consultas más simples. Es de lejos el esquema más fácil de trabajar.

3. XML. Esto es infinitamente flexible, pero la mayoría de las herramientas que rodean a la base de datos no funcionan bien con XML. También almacena el XML en unidades de asignación separadas de la tabla principal, por lo que puede causar problemas significativos con el rendimiento de la consulta. Las estrategias basadas en XML están muy centradas en la aplicación a expensas de otros consumidores de los datos.
   
   En mi experiencia, almacenar cantidades significativas de datos en campos XML en una base de datos aumentará significativamente el TCO de su aplicación. No recomendado para campos de datos de usuario en la mayoría de los casos.

Answer 3

Es interesante que no mencione ni el rendimiento ni la integridad de los datos como preocupaciones. Por lo que vale, el modelo n. ° 1 es el mejor enfoque para esas consideraciones.

La flexibilidad es muy sobrevalorada en lo que respecta a los modelos de datos. La mayoría de las estructuras de tablas son bien conocidas al inicio del desarrollo y se mantienen estables durante toda la vida de una base de datos. Si tiene una aplicación donde el modelo es genuinamente fluido e incognoscible, entonces probablemente no deba usar un RDBMS en absoluto. Elija uno de los productos NoSQL en su lugar.

Así que esa es otra votación para el # 1.

Answer 4

@marc_s No creo que uno pueda "casi siempre" hacer una selección entre las opciones anteriores. Hay un caso para apoyar ambas soluciones.

Opción # 1 Vaya para esto cuando la entidad X está bien definida, es decir, usted sabe exactamente lo que necesita capturar para definir X. En tal caso, un solo registro de X prácticamente captura todo un ejemplo de X representa.

Opción # 2 Vaya para esto cuando dicha entidad X no puede definirse completamente, es decir, usted no sabe qué atributos de conjunto se requieren para definirlo "completamente".

Por ej. tome un ejemplo de registro de empleado como se menciona en el artículo "Cinco errores simples de diseño de base de datos que debe evitar" [enlace provisto por @marc_s]. ¡¡¡Sí!!! Tendrá la tentación de obtener la Opción 1, pero si considera el caso de los empleados que trabajan en organizaciones grandes, una vez que solo registra la información del empleado, tanto su definición como el contenido es altamente dinámico y la combinación de la opción 1 y la opción 2.

Answer 5

Todas las soluciones tienen un problema por resolver. # 1 será un buen enfoque si conoce las columnas que necesita por adelantado. Sin embargo, en algunos casos, las columnas no se conocen por adelantado. Por ejemplo, campos personalizados que un usuario agrega a una funcionalidad.

Dicho esto, los EAV tienen una gran cantidad de problemas. Cuando se usan correctamente, IMO, son útiles.

1. Asegúrese de no crear un EAV para todo. Es solo para "elementos desconocidos".
2. Recuerde que los EAV no tienen relaciones de clave externa de las que depender.
3. El rendimiento es bajo debido a consultas no triviales, y el mantenimiento puede ser mayor.
4. Tenga en cuenta que los EAV deben pivotarse para que tengan sentido (bueno, con mayor frecuencia).

Answer 6

Como se dijo anteriormente, depende de sus requisitos. Debe elegir el n. ° 2 solo si necesita, por ejemplo, agregar nuevos tipos de atributos como parte del flujo de trabajo de su programa. Hacer esto agregando nuevas columnas en sus tablas es ciertamente peor que tener una tabla adicional y una combinación adicional en sus consultas.

Answer 7

@marc_s

Aunque he mencionado el ejemplo de registro de empleado estoy seguro de que no es muy convincente.

Este es el ejemplo del dominio financiero.

Si desea capturar todos los atributos de una oferta, entonces depende de su tipo de instrumento. Es mucho más fácil capturar la mayoría de los instrumentos de Forex, Money Market e incluso Bond, ya que están muy estructurados. Pero a medida que avanzamos hacia los productos derivados se vuelve muy engorroso. Son de naturaleza muy exótica y siguen cambiando en términos de estructura (de ahí su significado, etc.). Para capturar una información tan dinámicamente cambiante, debemos optar por EAV. Por supuesto, al hacer esta elección uno debe saber que trae muchos negativos enumerados arriba en su comentario.

No puedo hablar de otros dominios, pero estoy seguro de que los sistemas de TI en muchos dominios comerciales se enfrentan a esta situación y, por lo tanto, tener una buena comprensión de la estrategia de EAV se opondrá a su rechazo absoluto. buena idea.

Shrini