问题标签 [document-storage]

以下是否是实现版本控制的可行策略（使用“示例”作为示例文档类型）：

拥有一份原始文档，其中类型字段名为 example_original。

文档的后续更改都以 example_change 类型和 example_original 文档的 id 作为键。更改还将带有时间戳。

保留一个类型为 example_current 的文档，该文档是 example_original 的结果，所有 example_change “已应用”。一个新的 example_change 文档将自动应用于该文档。

查找特定版本将包括检索 example_original 文档并应用所需的更改（主要是到某个时间戳，但也可能是许多更改）。

我应该提一下，我的用例将涉及对原始用例的有限数量的更改。大多数更新将包含新的原始文档。虽然这是我当前的用例，但如果涉及到许多更改，我也会对可能导致的问题感兴趣。

您认为这种方法有哪些优点和缺点？

我们即将推出一个项目，我们将构建一个完整的后端 CMS 系统，该系统将通过一个软件包为我们的整个外联网和内联网提供动力。我一直试图找到答案的问题是哪个更好：将图像存储在数据库中（SQL Server 2005），这样我们就可以拥有完整性、单一复制计划等，或者存储在文件系统上？

我们遇到的一个问题是，我们有多个负载平衡的服务器，需要始终拥有相同的数据。到目前为止，我们有 SQL 复制来处理这个问题，但文件复制似乎有点困难。我们担心的另一个问题是，我们希望同一图像具有多个分辨率，我们不确定在文件系统上创建和存储每个版本是否是最好的，或者可能会根据请求动态提取和创建我们想要的分辨率图像。

我们的担忧是：

• 数据的完整性
• 数据复制
• 多种分辨率
• 数据库与文件系统的速度
• 数据库与文件系统的开销
• 数据管理和备份

有没有人有类似的情况或对推荐的内容有任何意见？在此先感谢您的帮助！

在过去的几天里，我一直在阅读文档并观看特定于 Mongo DB 的截屏视频，当这样的解决方案比典型的 pg 或 mysql 环境更好时，我不知所措。

具体来说，我的问题是在什么情况下（带有用例会很好）你想走 nosql 路线？

谢谢！

当使用文档数据库（如 couchdb）给出拥有多个子对象的对象示例时，始终建议将子对象附加到父对象。对于博客文章，这意味着您将所有评论添加为父博客文章对象的子对象。

但是，您这样做不会很快遇到限制吗？如果您的帖子有 800 条评论怎么办？如果您每页仅显示 100 条评论（尽管有些人将所有评论都显示在一个页面上），那不是对带宽和处理的巨大浪费。论坛主题或其他可能有大量孩子的事物也是如此。

• 有没有更好的方法来处理这个？
• 对象的大小有限制吗？
• 由于每次更新（每个新评论）都会再次创建整个对象，可能在短时间内用 800 份博客文章填充数据库，MVCC 是如何参与其中的？

我正处于 android 笔记应用程序的早期阶段，我希望有人能指出一个很好的解决方案来存储笔记数据。

理想情况下，我希望有一个解决方案：

• 每个笔记文档都是一个单独的文件（用于保管箱同步）
• 一个便笺可以由多个页面组成
• 笔记页面可以有二进制数据（例如图像）
• 可以加载单个页面，而无需将整个文档解析到内存中
• 线程安全：可以同时发生多个读/写。

XML 已经过时了（至少对于整个文件来说），因为我没有一个好的方法来一次提取一个页面。我考虑过使用 zip 文件，但是（特别是在压缩时）我认为它们也会被卡住加载整个文件。

似乎应该有一个 Java 库可以做到这一点，但我的 google-fu 让我失望了。我能想到的唯一其他选择是为每个笔记创建一个单独的 sqlite 数据库。

有人知道解决这个问题的好方法吗？谢谢！

有没有类似于 SQLite 但面向文档的数据库而不是 RDBMS 的东西？

Orient似乎与我正在寻找的东西相似，但它是用 Java 编写的，我正在寻找可以从 C++ 中使用的东西。

理想情况下，这将是一个无服务器系统，例如 SQLite。

将项目相关文档保存在 svn 中是个好主意吗？您可以为此推荐任何文档管理应用程序（sharepoint？）吗？问题是针对一个中等规模的软件公司（20 个开发人员）。

在一个应用程序中，我使用Fabric.js，它允许用户编写文本、绘制 SVG、插入图像等。
我想知道，存储这些数据的最佳方式是什么。

要求是：

1. 能够查询数据（文本），这告诉我应该将它存储在数据库中（截至目前的 MySQL）

2. 我有图像，而且我也以 iPad 为目标，因此图像对于它们的存储方式很重要。

3. SVG 和 HTML/CSS 也将被保存。

4. 我还想像 Quora 那样对内容进行版本控制，以便用户可以看到从过去版本到当前版本的更改。这还包括图像和 SVG 的版本控制。

我想知道 Google Docs 是如何做到的，因为它们还存储我们的文档、图纸等。

这样做的最佳方法是什么？

我是一名计算机工程师学生，我的作业基本上很简单，但我想让它更有趣一点:)。基本上，我必须使用 Java 或 .NET 创建一个简单的多用户在线文档版本控制系统。因为我更喜欢 .NET，所以我将使用 ASP.NET 或 Silverlight（尚未决定）。

无论如何，有趣的部分：我想使用 MongoDB 来存储文档（它们几乎可以是任何东西，视频、音频、简单的 MSOffice 文件、纯文本）、它们的每个版本和相关的元数据（它们所在的库、文件夹ETC）。我想将其他任何内容，例如用户、权限等（规范尚未完成）放入普通的关系数据库中。问题是您对此有何看法？你认为这有什么意义还是我只是想让整个事情复杂化？仅对所有内容使用 mongodb 或将 nosql 完全排除在外会更简单吗？这种东西有什么约定吗？:)

顺便提一句。在任何其他情况下，我都会使用一些免费的、经过实战测试的文档版本控制解决方案，但我必须自己设计和实现它，而且我正在尝试至少有点不合常规:)。

感谢您的每条评论:)，任何帮助表示赞赏:) 问候

我最近开始研究 RavenDB，并尝试看看它是否适合我们的某些项目。但是，我遇到了一些关于建模简单数据结构的“正确”方法的问题。我将尝试描述它：

• 有 3 种类型的对象：指南、类别和链接
• 一个“根”指南可以包含 0 个或多个子指南
• 一个指南可以包含 0 个或多个类别
• 一个类别可以包含 0 个或多个链接

从视觉上看，结构将是：

• 根指南（0个或更多）
  • 子指南（0个或更多）
    • 类别（0个或更多）
      • 链接（0个或更多）
  • 类别（0个或更多）
    • 链接（0个或更多）

在实际数据中，大约有20个根Guide，每个根Guide下大约有3-5个子Guide。在每个指南（根指南和子指南）下都有 15-25 个类别。每个类别下有 5 到 20 个链接。

我最初的想法是像这样建模（简化模型）：

这几乎是关系模型，我意识到这可能不是在 RavenDB 中建模数据的正确方法。那么替代方案是什么？我想问题是我不想像这样存储层次结构：

因为它会导致文档可能包含数千个子对象。请记住，上面的模型是简化的。实际上，每种类型都有更多的数据，因此如果我们采用这种模型，RavenDB 中的 20 个根指南文档将会非常庞大​​。

有没有其他选择？也许这是我多年来对关系数据库的不良教育，但也许这种情况根本不适合 RavenDB，也适合 SQL？

编辑（添加基本查询）

访问数据相当简单。我有以下要求：

1. 选择包含所有子指南的根指南列表。
2. 对于特定指南（根或子），获取所有子指南（如果是根）、类别和链接。

这基本上就是我所需要的。但是，评估 RavenDB 或类似数据库的原因之一是添加了一些搜索功能。正如我已经提到的，还有一些关于链接、类别和指南的更多信息，例如描述、标签等，因此能够搜索所有这些信息会很好。