帮助在 SQL/NoSQL 混合中建模 EAV (Sql server/RavenDB)答案

【问题标题】：Help with modeling EAV in SQL/NoSQL mix (Sql server/RavenDB)帮助在 SQL/NoSQL 混合中建模 EAV (Sql server/RavenDB)
【发布时间】：2011-05-22 07:42:49
【问题描述】：

我正在设计一个健康 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)
 },

}

这就是我目前所拥有的。除了一般意见（欢迎所有）之外，我想知道是否有人认为我应该将每位患者的所有事件和就诊记录在一份文件中，而不是每次就诊一份文件（以上应该是这样）。我相信文档可能会变得“太大”（不知道太大在基于文档的数据库中意味着什么）并且视图几乎总是基于访问 - 尽管我们还需要显示跨访问的趋势报告.

提前致谢！！

迈克

【问题讨论】：

您是否让 noSQL 和医疗保健数据以某种方式协同工作？我也有同样的问题。

标签： sql sql-server nosql data-modeling ravendb

【解决方案1】：

根据您的要求，这看起来很合适。

我认为可能还有其他事情发生，这可能是“状况”，不一定是任何患者事件的一部分。例如，患有高血压的人可能只是因为手指骨折而出现这种情况。

此外，事件可能难以定义 - 它是单一时间点事件还是恶化的渐进持续时间？也许这意味着事件实际上只是访问中的一个标记，或者您访问了访问关联表，它可以让您声明访问是另一次访问的后续，从而建立患者接受的护理的层次结构或网络。

只是一些想法......hth

编辑 - 事后诸葛亮：我肯定会推荐一个带有正确规范化表的 SQL 数据库...

【讨论】：

是的，你是对的，我遗漏了一件我们称之为病史/风险因素的部分，它们仅与患者相关，与任何事件或访问无关 - 我不想使发布，但我会在 NoSql 数据库中为上述记录创建一个单独的文档，因为它们也是一个潜在的广泛而稀疏的字段。
您是说您建议在 SQL 数据库中完成所有操作吗？稀疏问题呢？每个患者可能有数千个数据点，但很可能没有一个患者会拥有超过 10% 的数据点，如果有那么多的话，经过测试/使用。在 SQL 数据库中，我们需要为每一个潜在数据点设置一列，即使它们大多为空。
听起来应该换个思路。而不是数千个项目中的每一个的“列”，这些应该是“行”，然后您只会在需要时获得一行。
那将是 EAV 模型，对吗？这就是我最初计划做的事情，但将那部分放在基于文档的数据库中似乎更有意义。在 SQL 中使用 EAV，您基本上失去了 sql 数据库的所有优势（没有参照完整性、基数等）。
它不必是 EAV（我同意这有局限性）。我基本上只是在描述一个规范化，其中说程序代码在一个表中，然后这些代码通过 visit_procedure 表或其他东西与患者相关联......然后你不需要为每个可能的程序创建一个带有复选标记的列患者得到了哪些，而只是一行表明该患者在那次就诊期间对该患者执行了该程序。如果您需要一个新过程，则在过程表中添加一行并开始将其用作引用项，而不是在某处添加新列。

【解决方案2】：

混合使用数据库可能效果最好。现有方法使用 EAV，但问题在于嵌套事实 - 关于药物相互作用的警报可能是 SQL 表中的主事件

但是警报的严重程度，发送给谁，哪两种药物 - 这些详细信息可以转到基于文档的 noSQL 数据库。

【讨论】：