2

嗨，我是 mongodb 的新手。我正在使用 java。

我的关系表中有 4 个表租户、系统、授权。

像这样的东西。

Table            Fields

Tenant           Tenant_ID(PK), Tenant_INFO
System           System_ID(PK), System_Info
Authorization    System_ID, Autho_Info.
System_prop      System_ID, Prop_Info, Tenant_ID

在 System_prop 表中，Tenant_ID 是指租户表 Tenant_ID (PK)，System_ID 是指系统表 System_ID。

在 Authorization 表中，System_ID 是指 System 表 System_ID

我正在将我的数据库从关系数据库切换到 mongodb。我需要做的第一件事是架构设计。

我需要做的查询是：

  1. SELECT A.Prop_Info, A.System_ID From System_prop A, SYSTEM B, TENANT C 其中 A.System_ID = B.System_ID AND A.Tenant_ID = C.Tenant_ID

  2. SELECT A.System_ID, A.Prop_Info FROM Authoization A, SYSTEM B WHERE A.System_ID = B.System_ID

谁能帮助我如何将这些表设计为 mongodb 中的集合？

我需要嵌入 r 使用 dbref 吗？帮助我为此设计架构。

4

3 回答 3

2

您的挑战来自Prop_Info两个查询都必须检索的事实。这使得很难确定它应该放在哪个 Mongo 集合中。

在 MongoDB 中，您创建文档模式的理想目标是让单个文档在给定查询模式的情况下获得所需的所有信息。如果您需要两个单独的查询针对两个单独的集合返回相同的数据D（例如在您的情况下） ，您必须在以下三种策略之间进行选择：Prop_InfoAB

  1. 复制D和 的文档，A并B强制与您的代码保持一致。这通常是高性能系统的设计选择，他们希望消除对第二次查询的需求，即使这会以插入/更新方面的额外代码复杂性为代价，并且由于 Mongo 不是 ACID，因此存在一些潜在的一致性问题。

  2. 放入D并A存储一个引用（DBRef 或其他标识字段的组合），B以便您可以通过第二个查询获得它。A当查询数量超过查询数量时，这通常是设计选择B。它保持D本地到更频繁查询的集合。在这种模式设计模式中，您只需要在查询时进行第二次查询B。

  3. 放入D一个新集合C并从 和 对其进行第二次A查询B。面对非常不确定的未来需求，这通常是设计选择，如果您采用上述 (1) 或 (2)，则不清楚权衡将是什么。它是最“类似关系”的模式，当您同时查询A和时会强制您进行第二次查询B。

您选择哪种策略取决于您的领域、查询模式、您从对象关系映射 (ORM) 框架中获得的支持（如果您使用的话），最后但并非最不重要的一点是您的偏好。

在我遇到的情况下，我从来没有选择（3）。我在高性能情况（分析系统）中使用过（1）。我在其他任何地方都使用过 (2)，因为查询访问模式已经清楚地表明了“共享”数据应该存在的位置。

选择策略后，如果您仍然需要帮助，请发布另一个 SO 问题，该问题专门针对给定策略的架构设计问题。

最后三个提示：

  1. 如果共享数据D的关系多重性大于 1，则使用数组。您可以索引整个数组，并且可以使用$elemMatch.

  2. 要D在策略 (1) 或 (2) 中进行更新，请使用 MongoDB 的原子修饰符操作，其中许多操作旨在对数组进行操作。

  3. 这个 SO question涵盖了@Stennie 答案中的 DBRef 两个查询模式。（@Stennie 适用于 10gen，MongoDB 的标记。）

祝你好运！

于 2012-09-02T23:55:41.523 回答
2

您可能只需要一个包含所有文档的集合，当然您最终会拥有太多重复的字段，但这是很好地扩展的技巧。对于一对多和一对一类型的关系，您只需删除标识符并放置其余属性，因为 MongoDB 将处理主键。（'我喜欢 MongoDB'）。

对于租户和系统之间的多对多关系，您必须将其更改为 MongoDB 数据结构中的数组。

coll{
Tenant : 'value',
tenant_info : 'value',
Sys_info: 'value' ,
auth_info: 'value' ,
Prop_info : array [ 'value','value',''value....]
}
于 2012-09-03T01:11:52.970 回答
1

您仍在考虑关系数据库。然而，MongoDB 是一个面向文档的数据库。

  1. 通常不需要人工 ID 号，因为每个文档都会自动有一个 _id 字段，它是一个 GUID（保证全局唯一）。
  2. 关系表不应该在 MongoDB 中使用。n 型关系是用数组字段代替的。因此，当 1 个系统有 N 个它使用的授权时，您的系统文档应该有一个“授权”字段，它是它拥有的授权的对象 ID 的数组。是的，这将严重违反关系数据库的规范化规则。但是这里没有关系数据库。在 MongoDB 中，用数组表示 N 关系是很实用的，因为数组对查询语言是透明的。
于 2012-09-02T23:22:02.603 回答