针对 ODBC 支持的 NoSQL 文档存储的关系行为答案

【问题标题】：Relational behavior against a NoSQL document store for ODBC support针对 ODBC 支持的 NoSQL 文档存储的关系行为
【发布时间】：2015-07-01 20:29:37
【问题描述】：

第一个断言是，MarkLogic 和 Mongo 等文档样式的 nosql 数据库应该将每条信息存储在一个嵌套/复杂的对象中。

考虑以下模型

<patient>
    <patientid>1000</patientid>
    <firstname>Johnny</firstname>
    <claim>
        <claimid>1</claimid>
        <claimdate>2015-01-02</claimdate>
        <charge><amount>100</amount><code>374.3</code></charge>
        <charge><amount>200</amount><code>784.3</code></charge>
    </claim>
    <claim>
        <claimid>2</claimid>
        <claimdate>2015-02-02</claimdate>
        <charge><amount>300</amount><code>372.2</code></charge>
        <charge><amount>400</amount><code>783.1</code></charge>
    </claim>
</patient>

在关系世界中，这将被建模为患者表、索赔表和索赔费用表。

我们的主要愿望是同时向下游应用程序提供这些数据，同时对其进行分析。由于我们不想为每个度量编写一个复杂的程序，我们应该能够在此之上放置一个工具。例如，Tableau 声称通过 ODBC 与 MarkLogic 建立了本机连接。

当我们在文档模型上使用范围索引创建视图时，MarkLogic 中针对它的 SQL 返回过多的重复结果。电荷数也用求和函数重复计算。它不起作用。

我们的想法是，通过 MarkLogic 的这些索引、视图和可能的片段技术，我们可以定义一个类似于关系结构的语义层。

文档提示您应该为每个表创建 1 个对象，但这似乎违反了首选的文档数据库结构。

存储大量文档数据并在其之上提供交钥匙分析工具的数据建模和应用模式是什么？

如果 ODBC 连接总是返回错误的数据并且不知道关系，那么所有声称支持 NoSQL 的 ODBC 的工具都是不正确的。

参考文献

https://docs.marklogic.com/guide/sql/setup

https://docs.marklogic.com/guide/sql/tableau

http://www.marklogic.com/press-releases/marklogic-and-tableau-build-connection/

https://developer.marklogic.com/learn/arch/data-model

【问题讨论】：

标签： odbc data-modeling marklogic business-intelligence nosql

【解决方案1】：

我想 MarkLogic 与其他文档存储相比有点不典型。当您不将整个表存储为一个文档，而是每个文档一个记录时，它的效果最好。 MarkLogic 索引针对这种方法进行了优化，并通过这种方式轻松处理数百万个文档的搜索。您会看到，只要将记录存储为文档，Tableau 中的结果就会大大提高。

将文档拆分为如此小的片段还可以提高性能并减少占用空间。 MarkLogic 不会将数据保存为允许随机访问的持久 DOM 树。相反，它以一种非常有效的方式流式传输数据，并依靠索引解析来快速提取相关片段。..

HTH！

【讨论】：

我想澄清这个声明，因为它也在他们的网站上，正确的“每个文档一个记录”。这意味着每个患者的文档包含其患者属性，每个索赔的文档包含其声明属性。

【解决方案2】：

对于您的问题：“存储大量文档数据并在其之上提供交钥匙分析工具的数据建模和应用模式是什么？”

我使用的经验法则是，当我想计算“对象”时，我会将它们建模为单独的文档。因此，如果您想运行计算患者、索赔和费用的查询，您可以将它们放在单独的文档中。

这并不意味着我们将 MarkLogic 限制为仅使用关系模式。在 UML 术语中，一对多关系可以是组合或聚合。在关系模型中，我别无选择，只能将它们建模为单独的表。但是在文档模型中，我可以为每个对象创建单独的文档，或者将它们一起滚动——选择通常基于我想要查询数据的方式。

所以您的第一个断言部分正确 - 在文档存储中，您可以选择嵌套所有相关数据，但您不必这样做。另请注意，由于 MarkLogic 与模式无关，因此可以直接根据您的需求转换数据（corb 是一个很好的选择）。某些要求可能需要非规范化以帮助搜索高效运行。

简单示例 - 一个人可以有多个姓名（别名、婚前姓氏）和多个地址（不同的家庭、工作地址）。在关系模型中，我需要一个persons 表、一个names 表和一个addresses 表。但我认为名字是一种复合关系——名字的生命周期等于人的生命周期——所以我宁愿将这些名字嵌套到个人文档中。地址 OTOH 具有独立于人员的生命周期，因此我将其制作为地址文档并将元素扔到每个相关地址的人员文档中。从分析的角度来看，我现在可以就人员及其姓名、人员和地址提出许多有趣的问题——我只是无法有效地计算姓名，因为姓名不在单独的文档中。

【讨论】：