Помощь с моделированием EAV в SQL/NoSQL mix (Sql server/RavenDB)

Question

Я разрабатываю приложение SaaS для здоровья и буду признателен за помощь в начальном моделировании. Я начал с this thread, чтобы подтвердить, что я должен использовать EAV вообще - ответ был да из-за разреженности клинических данных. Затем я начал рассматривать возможность использования параметра NoSQL вместо того, чтобы пытаться поместить его в SQL. Кажется, комбинация этих двух будет работать лучше всего. Я постараюсь объяснить это требование и свою идею, и мне понравится любая обратная связь. Я использую .net.

Требование На самом высоком уровне у нас есть «Пациент». Чтобы пациент нуждался в какой-то медицинской помощи, что-то случилось бы, назовем это «Инцидент». Для каждого «Инцидента» «Пациент» можно увидеть несколько раз, называемый «Посещения». Все клинические данные (тесты/история/и т. Д.) Хранятся на «Посещение». Итак, мы имеем:

Пациент 1 - ∞ Инциденты 1 - ∞ просмотров 1 - 1 Клинические данные (многие потенциальные пары ключ/значение)

Решение (обратная связь будет здорово)

SQL Столы

Patient 
- PatientID 
- other patient info 

Incident 
- IncidentID 
- PatientID 
- Other incident info 

Visit 
- VisitID 
- IncidentID 
- Datetime 

NoSQL DocumentDB (вероятно 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) 
}, 

} 

Это то, что я до сих пор. Помимо общих мнений (все приветствуются), мне было интересно, думает ли кто-нибудь, чтобы я делал все инциденты и визиты для каждого пациента в ОДНОМ документе, а не один документ за посещение (что и должно быть выше). Я считаю, что документы могут быть «слишком большими» (без каких-либо представлений о том, что слишком важно в базе данных на основе документов), а также почти всегда взгляды основаны на посещении - хотя нам также нужно будет показывать трендовые отчеты по посещениям ,

Спасибо заранее!

Mike

Answer 1

Это выглядит подходящим в соответствии с вашими заявленными требованиями.

Я думаю, что, возможно, что-то происходит, что может быть «Условие», которое не обязательно является частью любого инцидента с пациентом. Например, человек с гипертонической болезнью может просто иметь это состояние, когда они представляют сломанный палец.

Кроме того, инцидент может быть трудно определить - это единая точка во времени или это прогрессивная длительность ухудшения? Возможно, это означает, что «Инцидент» - это просто маркер в посещении, или, может быть, вы посетили таблицу ассоциации vist, которая позволяет вам заявить, что посещение является продолжением другого визита, создавая иерархию или сеть ухода за пациентом.

только пара мыслей с верхним .. HTH

редактировать - второстепенные: Я бы точно рекомендовать SQL дб с правильно нормализованными таблицами ...

Answer 2

смесь баз данных может работать лучше.Существующие оценки используют EAV, но проблема связана с вложенными фактами - предупреждение о взаимодействии с наркотиками может быть главным событием в таблице SQL

, но затем, насколько серьезным предупреждением, которому отправлено, из которого 2 лекарства - эти данные могут перейти в документ, основанный на noSQL db.