NoSQL数据库设计的最佳实践

我刚刚开始使用基于NoSQL文档的数据库（MongoDB），并且对设计数据库的最佳实践感到好奇。

我认为体系结构应该与关系数据库不同？我是否仍应针对规范化的数据库？

例如，我有一个特定的用例。

我有一个具有租用历史记录（地址数组）的用户，该数组应该是用户数组还是具有共享密钥的单独集合？

NoSQL数据库设计的适当方法是DDD（域驱动设计）。对于以前设计RDBMS的某些人来说，NoSql看起来像Sql反模式，在DDD范围内考虑时，它更有意义。

根据地址的使用，您可以将其定义为租赁历史记录模型/实体中的值对象。

这里有一些参考资料，这些参考资料可能会清除有关使用NoSQL进行设计的想法：

• NoSQL管理员指南
• Wakanda：适用于模型驱动的Web应用程序的NoSQL-NoSQL涉及2012
• 解决NoSQL批评
• 我们在域名活动方面的经验

TL; DR

RDBMS中的规范化使您可以利用关系范式的优势。

NoSQL中的非规范化使您可以利用NoSQL范式的优势。

长答案

RDBMS很棒，因为它们使您可以对唯一的结构化实体（无论是否可变）及其彼此之间的关系进行建模。这意味着在实体级别上工作，更新其属性，插入另一个属性，删除一个属性等非常容易。但是，对于动态地将它们聚合，拥有所有者的狗，拥有住所的狗等也非常有用。 RDBMS为您提供了便利所有这些的工具。它会为您加入，它将为您处理各个实体之间的原子更改，等等。

NoSQL数据库之所以出色，是因为它们使您可以对半/非结构化聚合和动态实体进行建模。这意味着对不断变化的实体进行建模非常容易，这些实体并非都共享相同的属性和分层聚合。

要为NoSql建模，您需要考虑层次结构和聚合而不是实体和关系。因此，您没有人，出租地址以及它们之间的关系。您拥有租赁记录，这些记录可为每个人汇总他们拥有的租赁地址。

您需要问，我需要一起更改哪些数据。哪些数据在逻辑上将其他数据分组。在你的情况下，一个人听起来像一个很好的聚集体。通往其余数据的逻辑切入点是什么？

假设您说的是NoSQL，存储的是具有其他事物的事物，这些事物具有自己的事物。把事情的整个层次归还给我。让我随便更改它，现在用更改后的内容替换整个事物的层次结构。这就是给您的一切。为什么有用？如果您拥有的是事物层次结构，那么您始终会整体上进行交互。或者，如果您需要大规模扩展。

RDBMS给您的其他所有功能，您都必须在代码和架构中手动实现。如果您需要汇总，则必须加入代码。如果只需要聚合的一部分，则必须解析。如果您不想重复，则需要自己检查唯一性。跨聚合等工作时，您需要实现自己的事务逻辑。

因此，在一张大桌子上放着您需要的所有东西，这就是NoSql的方法。由于仅在该级别上保证原子性，所以性能也得到保证。尽早确定您的关系很重要。这就是非规范化。

在RDBMS中，非规范化实际上会使您的数据库瘫痪于NoSQL。所以通常您想要相反的东西，那就是规范化。如果不这样做，则应该改用NoSQL DB。除非您同时需要两者。