2
一起使用MongoDB和PostgreSQL
我当前的项目实质上是工厂文档管理系统的运行。 就是说，有一些皱纹（惊奇，惊奇）。尽管有些皱纹是该项目特有的，但我相信会出现一些一般性的观察和问题，它们没有规范的答案（无论如何我还是可以找到），并且适用于更广泛的问题领域。这里有很多东西，我不确定它是否适合StackExchange Q＆A格式，但我认为这是a）一个可以回答的问题，b）不够具体，足以使社区受益。我的某些注意事项是我特有的，但我认为该问题对于决定使用SQL，NoSQL和两者的任何人都可能有用。 背景： 我们正在构建的Web应用程序包含本质上关系明确的数据以及面向文档的数据。我们也想吃点蛋糕。 TL; DR：我认为下面的＃5通过了气味测试。你呢？有没有人有在单个应用程序中进行SQL和NOSQL集成的经验？我试图在下面列出解决此类问题的所有可能方法。我错过了一个有前途的选择吗？ 复杂性： 有许多不同类别的文档。这些要求已经需要数十种不同的文档。这个数字只会增加。最好的情况是我们可以利用一种简单的领域特定语言，代码生成和灵活的模式，以便领域专家无需DBA或程序员的干预即可处理新文档类的添加。（注意：已经知道我们遵守格林斯潘的第十条规则） 先前成功写入的完整性是该项目的核心要求。数据将对业务至关重要。如果成功写入的内容保持写入状态，则可以牺牲完整的ACID语义。 这些文件本身很复杂。在我们的特定情况下，原型文档将需要每个文档实例存储150多个不同的数据。病理情况可能会恶化一个数量级，但肯定不会两个。 单类文档是移动的目标，在以后的某个时间点会进行更新。 当我们将其连接到关系数据库时，我们喜欢从Django获得的免费内容。我们希望保留免费赠品，而不必跳回两个Django版本来使用django-nonrel分支。完全转储ORM优于降级到1.3。 本质上，它是关系数据（用户，组等典型的Web应用程序之类的东西，以及我们需要能够实时对复杂查询进行切片和切分的文档元数据）和文档数据（例如我们不希望加入或查询的数百个字段-数据的唯一用例是显示输入该文档的单个文档）。 我想对我的首选方法进行健全性检查（如果您检查自己的发帖历史，我很清楚我不是DBA），并列举了我为其他人解决的所有选项涉及关系和非关系数据的大致相似的问题。 拟议解决方案： 1.每个文档类一张表 每个文档类都有自己的表，其中包含所有元数据和数据的列。 好处： 标准SQL数据模型正在发挥作用。 关系数据以最佳方式处理。如果需要，我们将在以后进行非规范化。 Django的内置管理界面非常适合内省这些表，并且ORM可以愉快地使用100％开箱即用的数据。 缺点： 维护噩梦。数十个（几百个）数千列的表。 应用程序级逻辑负责确定要写入哪个表。使表名成为查询的参数很糟糕。 基本上，所有业务逻辑更改都将要求架构更改。 病理情况可能需要在多个表中剥离单个表单的数据（请参阅：PostgreSQL表中的最大列数是多少？）。 我们可能需要去寻找一个真正的，诚实的上帝DBA，毫无疑问，他最终会讨厌我们和生活。 2. EAV建模 只有一个字段表。实体-属性-值建模已经众所周知。为了完整起见，我将其包括在内。我认为在2013年启动的任何新项目都不会故意采用EAV方法。 好处： 易于建模。 缺点： 更难查询。 DB层不再对构成一个应用程序级对象的内容进行直接表示。 我们将丢失数据库级别的约束检查。 一张桌子上的行数将增长100-1000倍。从性能角度来看，可能是将来的痛点。 索引可能有限。 就ORM而言，DB模式是荒谬的。Web应用程序中包含的电池已保留，但自定义数据模型将需要自定义查询。 3.使用PostgreSQL的hstore或json字段 这些字段类型中的任何一个都可以解决在关系DB上下文中存储无模式数据的问题。我不立即跳到该解决方案的唯一原因是它是一个相对较新的版本（在8.4版中引入，所以不是那个新版本），以前对此没有零接触，并且对此表示怀疑。出于完全相同的原因，我感到不对，因为我会很不舒服地将所有漂亮的，易于规范化的数据扔到Mongo中，即使Mongo可以处理文档之间的引用，我也会感到不舒服。 好处： 我们获得了Django ORM以及内置的身份验证和会话管理的好处。 一切都保留在我们先前成功用于其他项目的一个后端中。 缺点： 没有经验，个人。 它看起来不像是一个非常常用的功能。看起来他们很受推荐给使用NOSQL解决方案的人们的欢迎，但我看不出有很多证据表明它们已被选中。这使我认为我一定想念一些东西。 所有存储的值都是字符串。丢失数据库级别的约束检查。 …