database - example - ¿Alternativas a Entity-Attribute-Value(EAV)?
entidad atributo valor (4)
Nuestra base de datos está diseñada en base al modelo EAV (Entity-Attribute-Value). Aquellos que han trabajado con modelos EAV conocen toda la mierda que viene con el propósito de flexibilidad.
Le pregunté a mi cliente sobre las razones por las que usaba el modelo EAV (flexibilidad), y su respuesta fue: sus entidades cambian con el tiempo. Por lo tanto, hoy pueden tener una tabla con algunos atributos, pero en un mes, se pueden agregar algunos atributos nuevos, o se puede renombrar un atributo existente. Necesitan generar informes para volver a cualquier etapa del tiempo y consultar los datos en función de la forma de las entidades en esa etapa.
Entiendo que esto no es factible con un modelo relacional convencional, pero personalmente veo a EAV como antipatrón. ¿Hay algún otro modelo alternativo que nos permita capturar la dimensión del tiempo en los cambios a las entidades e instancias?
Saludos, Mosh
Cree una nueva descripción de tabla para cada Versión de descripción de entidad y una tabla adicional que le indique qué tabla es qué versión. El sistema de consulta debería actualizarse también.
Creo que crear una secuencia de comandos que genere tablas y consultas es su mejor opción.
Hay una diferencia entre EAV hecho fielmente o mal; 5NF hecho por personas calificadas o por aquellos que no tienen ni idea.
La Sexta Forma Normal es la Forma Normal Irreductible (no es posible una mayor Normalización). Elimina muchos de los problemas que son comunes, como El problema nulo, y proporciona el último método para identificar los valores perdidos. Es la FN académica y técnicamente robusta. No hay productos para apoyarlo, y no se usa comúnmente. Para ser implementado de manera adecuada y consistente, requiere un catálogo de metadatos para ser implementado. Por supuesto, el SQL requerido para navegar es aún más engorroso (SQL ya es engorroso), pero esto se supera fácilmente mediante la automatización de la producción de SQL a partir de los metadatos.
EAV es un conjunto parcial o un subconjunto de 6NF. El problema es que, por lo general, se realiza con un propósito (permitir que se agreguen columnas sin tener que realizar cambios de DDL) y por personas que no conocen el 6NF y que no implementan los metadatos. El punto es 6NF y EAV ya que los principios y conceptos ofrecen beneficios sustanciales y el rendimiento aumenta; pero comúnmente no se implementa correctamente y los beneficios no se realizan. Bastantes implementaciones de EAV son desastres, no porque EAV sea malo, sino porque la implementación es deficiente.
P.ej. Algunas personas piensan que el SQL requerido para construir las filas 3NF de la base de datos 6NF / EAV es complejo: no, es engorroso pero no complejo. Lo que es más importante, se puede proporcionar una VISTA SQL ordinaria, de modo que todos los usuarios y herramientas de informe vean solo la VISIÓN 3NF directa, y los problemas de 6NF / EAV sean transparentes para ellos. Por último, el SQL requerido puede ser automatizado, por lo que el costo de mano de obra que soportan muchas personas es bastante innecesario.
Entonces la respuesta es realmente, la Sexta Forma Normal, ser el padre de EAV, y una forma más pura, es el reemplazo de ella. La advertencia es, asegúrese de que se haga correctamente. Tengo un gran db de 6NF, y no sufre ninguno de los problemas que publican las personas, funciona maravillosamente, el cliente está muy contento (ningún trabajo posterior es un signo de completa satisfacción funcional).
Ya he publicado una respuesta muy detallada a otra pregunta que también se aplica a su pregunta, que puede interesarle.
Independientemente del tipo de modelo relacional que utilice, el seguimiento de los cambios de nombre de campo requiere una gran cantidad de metadatos de los que debe hacer un seguimiento en los registros de transacciones o en las tablas de auditoría. Desafortunadamente, consultar cualquiera de esos para el estado en una fecha particular es muy complicado. Sin embargo, si su cliente solo requiere estado en una fecha de tiempo particular, es decir todo el estado, no solo con respecto a los cambios de nombre, puede duplicar la base de datos y retrotraer el registro de transacciones al tiempo particular requerido y ejecutar sus consultas en la nueva instancia . Sin embargo, si las entidades agregadas después de la fecha especificada necesitan aparecer en la consulta con los nombres de los campos anteriores, usted tiene un problema de ingeniería muy grande por delante. En ese caso, con la información que proporcionó en su pregunta, sugeriría ya sea negociar alternativas con el cliente u obtener más información sobre el uso de los informes para encontrar soluciones alternativas.
Podría moverse a un almacén de datos basado en documentos, pero eso aún no resolvería el problema en el segundo caso. Lamentamos que esta no sea realmente una respuesta, pero al haber pasado por situaciones similares, el cliente probablemente necesite una solución de informes más realista o un número de otros inversionistas dispuestos a destinar el capital para la ingeniería.
Cuando surgió este problema para nosotros, mantuvimos el esquema db constante e implementamos una fábrica de mapeo de entidades basada en una marca de tiempo. Al final, el cliente continuamente cambiaba los requisitos (de forma semanal a mensual) en cuanto a cómo se calculaban los campos agregados y nunca se satisfacían completamente.
Para agregar a las respuestas de @NickLarsen y @PerformanceDBA
Si necesita realizar un seguimiento de los cambios históricos en cosas como el nombre del campo, es posible que desee buscar algo así como Cambiar Dimensiones lentamente . Me parece que está utilizando el EAV para modelar modelos dinámicos dimensionales (probablemente listas de búsqueda).
La forma más simple (y probablemente menos eficiente) de lograr esto sería incluir un campo de fecha "a partir de" en las tablas EAV, y siempre que ocurra un cambio, inserte un nuevo registro (en lugar de actualizar un registro existente) con la fecha actual. Esto significa que debe modificar sus consultas para incluir siempre o buscar una fecha "a partir de", o desactivar "ahora" si no se proporciona ninguna. Su entidad base que se une a los objetos EAV tendría que consultar "top 1" desde la tabla EAV donde "fecha de entrada" es menor o igual que la fecha de la última actualización de la fila, ordenada por "a partir de" descendiendo En el peor de los casos, si necesita rastrear el cambio más reciente a una fila determinada donde tanto el nombre (almacenado en la tabla ''atributo'') como el valor han cambiado, debe encadenar esta lógica a la tabla de valores usando ''última modificación'' de la fila para encontrar el valor apropiado para esa fecha en particular.
Obviamente, esto tiene el potencial de generar GRANDES cantidades de datos si hay muchos cambios. Es por eso que a este enfoque se lo conoce como un cambio "lento". Está pensado para valores dimensionales que pueden cambiar, pero no muy a menudo. Para ayudar con el rendimiento de la consulta, los índices en los campos "a partir de" y "última modificación" deberían ser de ayuda.