Aide à la modélisation EAV en SQL/NoSQL mix (SQL Server/RavenDB)

Question

Je suis en train de concevoir une application SaaS santé et j'apprécierais de l'aide pour la modélisation initiale. J'ai commencé par this thread pour confirmer que je devrais utiliser EAV - la réponse était oui en raison de la rareté des données cliniques. J'ai alors commencé à chercher à utiliser éventuellement une option NoSQL au lieu d'essayer de l'intégrer dans SQL. Il semble qu'une combinaison des deux fonctionnerait mieux. Je vais essayer d'expliquer l'exigence et mes idées et aimerais tout commentaire. J'utilise .net.

Exigence Au plus haut niveau, nous avons un 'Patient'. Pour qu'un patient ait besoin d'aide médicale, quelque chose serait arrivé, appelons cela un «incident». Pour chaque "Incident", un "Patient" peut être vu plusieurs fois, appelé "Visites". Toutes les données cliniques (tests/histoire/etc) sont stockées par "Visite". Nous avons donc:

patient 1 - ∞ Incidents 1 - ∞ Visites 1 - 1 Les données cliniques (plusieurs clés potentielles/paires de valeur)

Solution (retour serait génial)

SQL tables

Patient 
- PatientID 
- other patient info 

Incident 
- IncidentID 
- PatientID 
- Other incident info 

Visit 
- VisitID 
- IncidentID 
- Datetime 

NoSQL DocumentDB (probablement RavenDB)

{ // Visit document - id: visits/12345 
"Patient": { 
    "PatientId": "patients/54321", 
    "Name": "John Smith" 
}, 
"Incident": { 
    "IncidentId": "incidents/55555", 
    "Name": "Cardiac Arrest" 
}, 
"VisitData": { 
    "BP": "110/70", 
    "Hypertension": "True" 
    "Cardiac Disease": "Angina" 
    "Stroke": "False" 
    .... (could be tens or hundreds of key/value pairs) 
}, 

} 

C'est ce que j'ai jusqu'à présent. Mis à part les opinions générales (toutes bienvenues), je me demandais si quelqu'un pensait que je devrais mettre tous les incidents et visites pour chaque patient dans un document plutôt que d'avoir un document par visite (ce qui est censé être). Je crois que les documents pourraient être «trop gros» (sans aucune idée de ce qui est trop gros dans un document DB) et aussi presque toujours les vues sont basées sur une visite - bien que nous ayons besoin de montrer des tendances aussi bien dans les visites. .

Merci d'avance !!

Mike

Answer 1

Cela semble approprié selon vos exigences.

Je pense qu'il y a probablement quelque chose d'autre qui se passe, qui est peut-être «condition» qui ne fait pas nécessairement partie d'un patient incident. Par exemple, une personne souffrant d'hypertension peut simplement avoir cette condition quand ils se présentent pour un doigt cassé.

En outre, l'incident peut être difficile à définir: s'agit-il d'un événement ponctuel ou d'une durée de détérioration progressive? Peut-être que cela signifie que Incident est vraiment un marqueur lors d'une visite, ou peut-être vous avez une visite à la table d'association de vist qui vous permet de déclarer qu'une visite est un suivi d'une autre visite, établissant une hiérarchie ou un réseau des soins reçus.

seulement une pensée couple sur le haut .. HTH

modifier - après coup: Je recommande que pour un db SQL avec des tables correctement normalisées ...

Answer 2

un mélange de bases de données peut fonctionner au mieux.Les appraches existantes utilisent EAV mais le problème est avec des faits imbriqués - alerte sur l'interaction médicamenteuse pourrait être l'événement maître dans un tableau SQL

mais alors comment sévère alerte, à qui envoyé, quels 2 médicaments - ces détails peuvent aller à un document- basé sur noSQL db.