，所以我正在nodejs＆amp;Expressjs。这是我第一次使用诸如MongoDB之类的NOSQL数据库，并且我试图弄清楚如何修复数据模型。
在我们的项目开始时，我们已经写下了关系数据库术语中的所有内容，但是由于我们最近从Laravel转换为" Expressjs"的项目，所以我对所有不同表的布局有些困扰。
到目前为止，我已经弄清楚了否定性 它确实必须在某个地方结束，对吗？最后，您最终可以将整个数据存储在一个集合中。好吧，不是进入，但你明白了。
1。因此，是否有一个 rule 或标准定义了要切割多个集合的位置？我与用户（既是客户端或商店用户），商店，产品，购买，类别，子类别的关系数据库。
2。在NOSQL数据库中定义关系不好？就像每个产品都有一个类别一样，但我想通过ID与该类别（父母在MongoDB中做工作）相关，但这是一件坏事吗？还是您选择性能与结构的地方？
3。NOSQL/MONGODB是否用于如此大的数据库，这些数据库具有很大的关系（如果它们是在MySQL中建立的）？
预先感谢
正如已经编写的，没有像SQL的第二个正常形式那样的规则。
但是，我将在此处列出一些与优化的最佳实践和常见的陷阱。
过度使用嵌入
BSON限制
与普遍的信仰相反，参考文献没有错。假设您有书库，您想跟踪租金。您可以从类似的模型开始
{
// We use ISBN for its uniqueness
_id: "9783453031456"
title: "Schismatrix",
author: "Bruce Sterling",
rentals: [
{
name:"Markus Mahlberg,
start:"2015-05-05T03:22:00Z",
due:"2015-05-12T12:00:00Z"
}
]
}
虽然该模型存在几个问题，但最重要的并不明显 - 租金数量有限，因为BSON文档的尺寸限制为16MB。<<<<<<<<<<<<<</p>
将租金存储在数组中的另一个问题是，这将导致相对频繁的文档迁移，这是一个相当昂贵的操作。BSON文档永远不会被分区和创建，并在生长时提前分配了一些额外的空间。这个额外的空间称为填充。超过填充物后，将文档移至数据文件中的另一个位置，并分配了新的填充空间。因此，频繁添加数据会导致频繁的文档迁移。因此，最好的做法是防止频繁更新增加文档的大小并使用参考。 因此，对于这个例如，我们将更改单个模型并创建第二个模型。首先，这本书的模型 租赁的第二个模型看起来像 当然可以使用相同的方法。 让我们回顾一下。开发人员将确定涉及业务案例的实体，定义其财产和关系，编写根据实体类，将头撞在墙上几个小时，以获取三重Inner-Outer-obove-above-and-Beyond加入所需的工作对于用例，所有人都过着幸福的生活。那么，为什么通常使用NOSQL，尤其是MongoDB呢？因为没有人幸福地生活。这种方法可怕地缩放，几乎完全是缩放尺度的唯一方法是垂直的。 但是NOSQL的主要区别在于，您是根据需要回答的问题对数据进行建模的。 话虽如此，让我们看一个典型的n：m关系，并以作者与书籍的关系为例。在SQL中，您将有3个表：三张表：您的实体（ books and 作者），一个用于关系（谁是哪本书的作者？）。当然，您可以拿那些桌子并创建它们的等效收藏。但是，由于MongoDB没有加入，因此您需要三个查询（一个针对第一个实体，一个用于其关系，一个用于相关实体）才能找到一个实体的相关文档。这是没有意义的，因为n：m关系的三个表方法是专门发明的，以克服严格的STEMAS SQL数据库强制执行。由于MongoDB具有灵活的架构，因此第一个问题将是在哪里可以存储关系，从而使嵌入过度使用所产生的问题。由于作者可能会在即将到来的几年中写几本书，但是一本书的作者很少（如果有的话）更改，答案很简单：我们将作者存储在书籍数据 现在我们可以通过进行两个查询来找到该书的作者： 我希望以上可以帮助您决定何时实际"拆分"您的收藏品并解决最常见的陷阱。 关于您的问题，这是我的答案文档迁移问题
{
_id: "9783453031456",
title:"Schismatrix",
author: "Bruce Sterling"
}
{
_id: new ObjectId(),
book: "9783453031456",
rentee: "Markus Mahlberg",
start: ISODate("2015-05-05T03:22:00Z"),
due: ISODate("2015-05-05T12:00:00Z"),
returned: ISODate("2015-05-05T11:59:59.999Z")
}
过度归一化的问题
{
_id: "9783453526723",
title: "The Difference Engine",
authors: ["idOfBruceSterling","idOfWilliamGibson"]
}
var book = db.books.findOne({title:"The Difference Engine"})
var authors = db.authors.find({_id: {$in: book.authors})
结论
_id，则很容易找到相关产品。加载产品时，您可以轻松地获得其属于的类别，甚至有效地，因为默认情况下_id索引。
在选择" nosql"解决方案上以"关系"解决方案存储时要考虑的"第一个"事物是，"事物"事物"不以相同的方式工作，因此响应不同通过设计。
更具体地说，诸如mongoDB之类的解决方案不是"仿真"关系"中存在的"关系联接"结构，因此在许多SQL中存在，因此"关系"后端，并且它们是旨在查看数据的"关系"结构。"以一种非常不同的方式。
这是您的"问题"，如下所示：
-
确实没有集合的"规则"，并且理解命名的"规则"在这里不适用，原因是NOSQL解决方案存在的基本原因。那就是提供可能对您的情况很好的"不同"的东西。
-
不好吗？好吗？两者都是主观的。考虑到点" 1"，有一个基本考虑，即"非关系"或" nosql"数据库旨在"以不同的方式"进行关系。因此，通常会有"惩罚"以一种关系方式"模仿加入"。专门针对MongoDB，这意味着"其他请求"。但这并不意味着您"不能"或"不应该"这样做。相反，这全都是关于您的使用模式如何适用于您的应用程序。
-
在上面提出的基本点上重新加封，NOSQL通常旨在解决不适合传统SQL和/或"关系"设计模式的问题，因此可以用其他东西代替它们。这里的"最终目标"是为了让您"重新考虑数据访问模式"，并将您的应用程序发展为使用更适合您在应用程序使用中访问它的存储模型。
简而言之，没有严格的规则，这也是摆脱" nth-formal形式"规则的重点的一部分。NOSQL解决方案（例如MongoDB）允许典型的SQL/关系解决方案以有效形式提供的"嵌套结构"存储。
另一方面是考虑到"加入"诸如"大数据"表格的操作不会"缩放"表单，因此存在不同的方式来通过提供诸如"嵌入式数据结构"，，"加入"的方式。例如MongoDB。
您将对一些NOSQL解决方案接近存储和访问数据的主题进行真实指南。最终，您需要决定确定哪种最适合您和您的应用程序。
在一天结束时，应该意识到何时SQL/关系模型不满足您的需求，然后选择其他东西。