我在MLCP中使用CSV文件加载了一堆规范化文档。如何使用主键(比如ID)定位所有相关文档并将它们合并为一个非规范化文档？我还需要更改初始文档中的一些值。
这是MarkLogic的数据中心框架(DHF)的主要用例-https://marklogic.github.io/marklogic-data-hub/。您仍然可以将CSV文件吸收到MLCP中(这将是进入暂存数据库的"原始"数据)，然后DHF提供一些管道来编写"协调"流，将所有相关文档合并到一个文档中(这些文档将进入您的最终数据库)。
您也可以使用CoRB-https://developer.marklogic.com/code/corb。DHF类似于CoRB，但对于这类用例有更多的管道。
对于任何大型工作或正在进行的流程，使用@rjrudin这样的框架肯定是可行的。然而，实验仍然有助于了解你要求框架做什么。
我建议您从使用与RDBMS模式设计相同的过程开始——考虑查询。从数据/应用程序的主要用户那里获得"前十名"列表，了解最需要什么类型的查询/问题，以及预期的结果和格式，这很有用。断章取义的去规范化并没有那么有用——(一个极端的例子是简单地将所有数据放在一个"去规范化"的文档中——可能没有用处)。
一个简单但有用的概念是，MarkLogic对于基于"文档"的问答非常有效。"像谷歌一样思考"。当你使用谷歌时，你在寻找什么？你在找网站吗？还是提炼出简明扼要的"事实"？添加/统计？如果您的查询主要是"给我所有包含XYZ信息的文档"，那么您可能希望将其反规范化为以"XYZ"主题为中心的文档。如果您的域具有以文档为中心的自然信息分组(例如制药公司具有"药物"相关文档，旅游公司具有"财产"相关文档)。非常重要的是要记住，搜索和文档创建/更新都在"文档"级别运行，然后让您预期的查询和结果集指导您对"文档"的定义，而不是仅基于外键创建文档从规范化视图中提取的关系。在经典的"商业文档"中例如，如果您的业务领域有以"发票"one_answers"采购订单"为中心的工作流，那么将每个发票作为一个单独的文档是有意义的，可能会将所有行项目的详细信息嵌入其中。然而，如果业务工作流专注于库存管理，则对每个库存部分的文档建模可能更有意义，可能在每个部分中嵌入订单详细信息，或者两者兼而有之。
一旦您决定了文档模型，反规范化的机制就非常简单了——它几乎与RDBMS Join查询相同——只是您不必创建固定的"行"one_answers"列"。QConsole内部的XQuery是一个很好的文档模型实验平台。然后，当您完成它时，过渡到所描述的框架之一应该很容易。
订单/项目文档反规范化的一个粗略示例可能如下所示：(伪代码)
for $order in /order_recored_csv/order
let $doc := <order> {
$order/*,
for $line_item in /item_record_csv/line_item[ order_id = $order/order_id ]
return
<line>{ $line_item/* except $line_item/order_id }</line>
}
</order>
return xdmp:document-insert( "/orders/{$doc/order_id}" , $doc )
这将创建一组"订单"文档，每个文档中都有关联的行项目。
然后，您可能希望通过添加客户信息、数据丰富(将ID转换为值、从外部源查找数据、分配唯一标识符、版本控制、数据源引用等)来进行改进。