我们目前有一个很好的关系型sql server 2008数据库，它是我们的主应用程序数据库。我们正在寻求改进现有的文档存储机制，该机制使用xml数据类型和更无模式的东西，可以处理类似但不相同的文档，并认为couchdb非常适合。
这个想法是关于文档的公共元数据可以存储在sql server中以便于显示/聚合/报告，但实际文档存储在沙发中以处理文档中的细微差别。我们的想法是充分利用两种不同的技术。
例如，创建的状态，类型，相关人员和日期在所有文档中都是通用的并存储在sql中，但是电子邮件和信件（显然具有不同的字段）可以存储在沙发中。
然后我们可以显示所有类型文档（数千个文档）的文档网格，这些文档可以通过sql查询，但是当用户请求查看文档时，doc的显示从沙发中获取数据。
需要记住的是，某些文档类型是从也是文档本身的模板生成的（想想邮件合并/查找和替换）。
应用层是asp.net 4.5，c＃，存储库模式，Windsor for ioc，JavaScript
那么，对于这个问题......
这种方法是否能够充分利用两种不同的数据存储范例？
我们是否希望“使用最合适的技术解决问题”，使我们的编程生活变得不必要复杂？
有没有人有尝试过类似事情的经历，如果有的话，它是怎么回事？
答案 0 :(得分：2)
对文档使用两种不同的存储格式并不罕见：一种用于可搜索的方面和元数据，另一种用于演示。
以更一般的方式看待它，这种方法有点类似于我们在丹麦皇家图书馆开发并推进欧洲行星项目的方法：
这是另一篇以更一般的方式讨论这种方法的论文： "Opening Schrödingers Library"
目标是存档。我们认识到，在转换文档进行存档或保存时，没有信号存储格式在保留原始文档的属性，格式，外观，内容等方面都是优越的。解决方案：转换为多种格式，并使用复杂的数字对象来跟踪转换，以及哪种转换方式最能保留原始方面。
因此，在我看来，这种方法在理论上和实际上都是合理的。
实际问题：您可能需要某种数字对象来跟踪文档的各个部分，例如。它是仅发生在一个系统中（以及哪一个），或两者兼而有之。看来你打算在这方面使用SQLserver，这听起来很合理。
我们确实实现了我们在论文中描述的对象模型，最后我听说他们仍在使用它。