sql - Alternativas al modelo EAV vs Estrategia Híbrida versus simplificación y mejora de construcciones
database-design entity-attribute-value (1)
He estado haciendo una tonelada de investigación sobre diseño de bases de datos para un próximo proyecto.
Este es el problema clásico de la plataforma interna , donde nuestro cliente básicamente desea personalización infinita y la capacidad de crear formularios y atributos en una entidad, recopilar valores de los usuarios finales y poder mostrar la información recopilada en gráficos.
En habrá algo utilizado por los médicos para ayudar a controlar a los pacientes, y por qué incluso el uso de EAV es una idea es que tendremos que recopilar información diferente para diferentes pruebas. A veces puede ser lo que comieron ese día. Otros podría ser azúcar en la sangre o presión sanguínea (que en realidad son dos números), y otras veces podría haber múltiples preguntas (¿cómo está hoy su dolor entre 1 y 10?), Todo con la idea de que nunca lo sabremos realmente. anticipar qué es exactamente lo que pedirá el cliente final, o cuáles serán los valores aceptados.
También graficaremos estos datos consistentemente a lo largo del programa y generaremos informes más grandes de forma menos regular.
Idealmente, me gustaría poder codificar tanto como sea posible, ya que estamos usando SQL, y apegarnos a las mejores prácticas de la base de datos relacional simplificará tanto el diseño de la base de datos como el diseño de la aplicación (que estoy escribiendo).
Estamos haciendo algunas pruebas, y mi primera inclinación es obtener la mayor cantidad de información posible de los clientes, codificar las tablas en la base de datos y luego compilar desde allí. Si descubrimos que NECESITAMOS usar una tabla de atributos y una tabla attribue_value para recopilar esos atributos (junto con elementos de creación de formularios divertidos para implementar, como elementos desplegables y, por lo tanto, las opciones del menú desplegable y la validación / requisitos), podríamos hacerlo para más tarde se lanza.
He revisado básicamente todas las publicaciones de desbordamiento de pila relevantes; la mayoría dice que evite EAV, entienda mejor los requisitos de la aplicación y, en algún momento, si el cliente REALMENTE necesita una implementación de EAV, siga adelante y hágalo.
¿Alguien ha usado alguna vez un modelo híbrido? ¿Puedes discutirlo?
¿Alguna vez alguien ha implementado con éxito el modelo de EAV, y puede discutirlo?
¿Ha estado en una decisión similar, decidió no implementar EAV para un proyecto que parecía que podría haber sido un candidato? ¿Cómo resultó eso?
Aquí hay algunas lecturas interesantes que he encontrado en el camino:
http://decipherinfosys.wordpress.com/2007/01/29/name-value-pair-design/ ¿ Almacena datos de series temporales, relacionales o no? Base de datos EAV Pros / Cons y Alternativas Alternativas a Entity-Attribute-Value (EAV)?
Después de pensar un poco, y teniendo en cuenta las necesidades / solicitudes de los clientes, el uso de un modelo EAV fue la respuesta correcta aquí.
Después de investigar un poco más, decidí usar Postrgresql y utilizar al máximo su tipo de datos HSTORE, que permite almacenar, buscar e indexar pares de valores clave en un solo campo.
Aquí hay un papel benchmarking hstore vs EAV: http://wiki.hsr.ch/Datenbanken/files/Benchmark_of_KVP_vs. hstore -_doc.pdf
El documento sobre benchmarks hstore vs una tabla EAV, y hstore salió mucho más adelante.
Otra opción que consideramos fue tener una tabla de tareas que cubría todas las bases:
id, name, value_1, value_2 ... note_1, notes_2
Obviamente, la idea de eso me mató un poco, así que iba a usar una tabla de atributos task_type:
una tarea es prescrita por un administrador a un usuario y tiene un tipo_tarea, los atributos_tipo_tarea son para todas las tareas de ese tipo (es decir, definen que para una tarea de ejercicio, queremos poder almacenar información sobre la intensidad del ejercicio, el tiempo que tomó el ejercicio, etc.).
Una vez que el usuario abre la tarea, ellos ven los atributos de la tarea como campos para completar. Ingresan a estos campos, y los valores_atributo que ingresan se asocian luego con la entrada_tarea del paciente (que también indica si la completaron, la saltaron, etc.)
task_attributes
- carné de identidad
- task_type_id
- atributo
- attribute_value_type (para generar los campos deseados en el lado de la aplicación, es decir, saber tener un menú desplegable frente a una entrada de texto)
- min_value
- valor máximo
- necesario
tasK_entry_values
- task_entry_id
- task_type_attribute_id
- valor
Espero que esto pueda ser útil para alguien. También me interesaría cualquier crítica / comentario sobre este diseño.