6

我们目前有一个关系很好的 sql server 2008 数据库，它是我们的主应用程序数据库。我们正在寻求改进现有的文档存储机制，该机制使用 xml 数据类型和更无模式的东西，可以处理相似但不相同的文档，并认为 couchdb 非常适合。

这个想法是关于文档的通用元数据可以存储在 sql server 中以便于显示/聚合/报告，但实际文档存储在沙发上以处理文档中的细微差异。我们的想法是充分利用这两种不同的技术。

例如，创建的状态、类型、相关人员和日期都将在所有文档中通用并存储在 sql 中，但电子邮件和信件（显然具有不同的字段）可以存储在沙发上。

然后我们可以为所有类型的文档（数千个文档）显示我们的文档网格，这些文档可以通过 sql 查询，但是当用户请求查看文档时，文档的显示会从沙发上获取其数据。

需要记住的是，某些文档类型是从模板生成的，这些模板本身也是文档（想想邮件合并/查找和替换）。

应用层是asp.net 4.5, c#, repository pattern, Windsor for ioc, JavaScript

那么，对于这个问题...

这种方法是充分利用两种不同的数据存储范例的明智方法吗？

为了“使用最合适的技术解决问题”，我们是否让我们的编程生活变得不必要的复杂？

有没有人尝试过类似的事情，如果有，效果如何？

4

1 回答 1

2

对文档使用两种不同的存储格式并不罕见：一种用于可搜索的方面和元数据，另一种用于演示。

从更一般的角度来看，这种方法有点类似于我们在丹麦皇家图书馆开发并在 Planets EU 项目中推出的方法：

http://www.researchgate.net/publication/221176211_Archive_Design_Based_on_Planets_Inspired_Logical_Object_Model

这是另一篇以更一般的方式讨论这种方法的论文： “Opening Schrödingers Library”

目标是归档。我们认识到，在转换文档以进行归档或保存时，没有一种存储格式在保存原始文档的属性、格式、外观、内容等的所有方面都具有优势。解决方案：转换为多种格式，并使用复杂的数字对象来跟踪转换，以及原始的哪些方面在哪些转换中保存得最好。

所以在我看来，这种方法在理论上和实践上都是合理的。

实际问题：您可能需要某种数字对象来跟踪文档的各个部分，例如。它是否只发生在一个系统中（以及哪个系统），或者两者都发生。看来您将在这方面使用 SQLserver，这听起来很明智。

我们确实实现了我们在论文中描述的对象模型，最后我听说他们仍在使用它。

于 2012-11-30T10:39:33.707 回答