Question

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

考虑以下模型

<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声称与MarkLogic具有本机连接，即通过ODBC。

当我们在文档模型上使用范围索引创建视图时，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

Answer 1

对于您的问题：＆＃34;什么是用于存储大量文档数据的数据建模和应用程序模式，然后在其上提供交钥匙分析工具？＆＃34;

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

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

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

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

Answer 2

我猜MarkLogic与其他文档商店相比有点不典型。当您不将整个表存储为一个文档，但每个文档只存储一个记录时，它最有效。 MarkLogic索引针对此方法进行了优化，并以这种方式轻松处理数百万个文档。您将看到，只要将记录存储为文档，Tableau中的结果就会大大改善。

将文档拆分为这样的小碎片也可以实现更高的性能和更低的占地面积。 MarkLogic不会将数据保存为允许随机访问的持久DOM树。相反，它以非常有效的方式流式传输数据，并依赖索引解析来快速提取相关的片段。

HTH！

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

2 个答案: