小编chu*_*ash的帖子

我目前的项目本质上是一个工厂文件管理系统的运行。

也就是说，有一些皱纹（惊喜，惊喜）。虽然有些问题是项目特有的，但我相信有一些普遍的观察结果和问题没有规范的答案（无论如何我可以找到）并且适用于更广泛的问题领域. 这里有很多，我不确定它是否适合 StackExchange Q&A 格式，但我认为它 a) 一个可回答的问题和 b) 不够具体，它可以使社区受益。我的一些考虑是特定于我的，但我认为这个问题对任何面临决定 SQL 还是 NoSQL 还是两者的人都有用。

背景：

我们正在构建的 Web 应用程序包含本质上具有明显关系的数据以及面向文档的数据。我们想吃蛋糕，也想吃。

TL;DR：我认为下面的 #5 通过了气味测试。你？有没有人有将 SQL 和 NOSQL 集成到单个应用程序中的经验？我试图在下面列出解决此类问题的所有可能方法。我错过了一个有前途的替代方案吗？

复杂性：

• 有许多不同类别的文档。这些要求已经需要数十种不同的文件。这个数字只会上升。最好的情况是，我们可以利用简单的领域特定语言、代码生成和灵活的模式，以便领域专家可以在没有 DBA 或程序员干预的情况下处理新文档类的添加。（注意：已经意识到我们正在实践Greenspun 的第十条规则）
• 以前成功写入的完整性是项目的核心要求。这些数据对业务至关重要。可以牺牲写入的完整 ACID 语义，前提是成功写入的内容保持写入状态。
• 文件本身很复杂。在我们的特定案例中，原型文档需要为每个文档实例存储 150 多个不同的数据片段。病理情况可能会更糟一个数量级，但肯定不是两个。
• 一类文档是一个移动的目标，在稍后的时间点会更新。
• 当我们将 Django 连接到关系数据库时，我们喜欢从 Django 获得的免费东西。我们希望保留免费赠品，而不必跳回两个 Django 版本来使用 django-nonrel fork。完全转储 ORM 比降级到 1.3 更可取。

从本质上讲，它是关系数据（您的典型 Web 应用程序内容，如用户、组等，以及我们需要能够实时对复杂查询进行切片和切块的文档元数据）和文档数据（例如我们没有兴趣加入或查询的数百个字段 - 我们对数据的唯一用例将是显示输入的单个文档）。

我想对我的首选方法进行完整性检查（如果你检查我的发帖历史，我非常明确地说明我不是 DBA），并列举我遇到的所有选项供其他人解决涉及关系和非关系数据的广泛相似的问题。

建议的解决方案：

1. 每个文档类一张表

每个文档类都有自己的表，其中包含所有元数据和数据的列。

好处：

• 标准 SQL 数据模型正在发挥作用。
• 以最好的方式处理关系数据。如果需要，我们稍后会进行非规范化。
• Django 的内置管理界面可以轻松地检查这些表，并且 ORM 可以 100% 使用开箱即用的数据。

缺点：

• 维修噩梦。数十（数百？）个表（数十？）数千列。
• 应用程序级逻辑负责准确决定要写入哪个表。将表名作为查询的参数很糟糕。
• 基本上所有业务逻辑更改都需要架构更改。
• 病理情况可能需要为跨多个表的单个表单条带化数据（请参阅：PostgreSQL …

目前是否计划标准化一种限制查询返回结果数量的最佳方法？

是否有 ANSI SQL 替代 MYSQL LIMIT 关键字的堆栈溢出问题？列出了用不同语言处理这种行为的各种方法：

DB2 -- select * from table fetch first 10 rows only 
Informix -- select first 10 * from table 
Microsoft SQL Server and Access -- select top 10 * from table 
MySQL and PostgreSQL -- select * from table limit 10 
Oracle -- select * from (select * from table) where rownum <= 10

我不经常玩数据库，所以我在这里说的是无知，但似乎这是一个非常重要的功能 - 至少足够重要，当我看到它被留给供应商时我会挠头。