Помогите с моделированием EAV в смеси SQL / NoSQL (Sql server / RavenDB) - PullRequest
Новая
       14

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

6 голосов
/ 08 декабря 2010

Я занимаюсь разработкой приложения SaaS для здоровья и буду признателен за помощь в первоначальном моделировании.Я начал с этой темы , чтобы подтвердить, что мне вообще следует использовать 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)
 },

}

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

Заранее спасибо !!

Майк

Ответы [ 2 ]

0 голосов
/ 21 сентября 2012

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

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

0 голосов
/ 08 декабря 2010

это выглядит уместно в соответствии с вашими заявленными требованиями.

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

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

просто пара мыслей с верху .. hth

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

...