与NoSQL数据库的关系

Question

这个问题是针对所有NoSQL以及特别是mongoDB专家的。 我从为项目设计关系数据库开始，但是客户希望我们使用可以轻松扩展的数据库。 为了实现这一目标，我们决定使用mongoDB。 这些天，我在为NoSQL映射我的关系模型时遇到了麻烦。 我有一个用户表，该表与许多其他表具有多对多关系，如下所示：

将其转换为mongoDB时，我有一些选择：

选项1（用户中有完整的行）：

users:{
  _id:<user_id>,
  battles:{[battle1, battle2, ...]},
  items:{[item1, item2, ...]},
  locations:{[location1, location2, ...]},
  units:{[unit1, unit2, ...]},
}

battles:{
  <battle_info>
}

locations:{
  <location_info>
}

units:{
  <units_info>
}

items:{
  <items_info>
}

选项2（仅在用户中使用外键）：

users:{
  _id:<user_id>,
  battles:{[battle1_id, battle2_id, ...]},
  items:{[item1_id, item2_id, ...]},
  locations:{[location1_id, location2_id, ...]},
  units:{[unit1_id, unit2_id, ...]},
}

battles:{
  <battle_info>
}

locations:{
  <location_info>
}

units:{
  <units_info>
}

items:{
  <items_info>
}

选项3（其他表中的用户ID）：

users:{
  _id:<user_id>,
}

battles:{
  <battle_info>,
  user:{[user1_id, user2_id, ...]}
}

locations:{
  <location_info>,
  user:{[user1_id, user2_id, ...]}
}

units:{
  <units_info>,
  user:{[user1_id, user2_id, ...]}
}

items:{
  <items_info>,
  user:{[user1_id, user2_id, ...]}
}

选项1有很多重复项，因为我们要添加其他表的完整行。 我看到的一个问题是，如果某个项目或战斗已更新，我们将不得不在users表中查找所有出现的事件并进行更新。 但这给我们带来了始终拥有一个完整的用户对象的优势，该对象可以在登录时移交给客户端应用程序。

选项2是更相关的，其中在users表中只有其他表的mongoIds。 此选项的优点是更新战斗或项目没有太多成本，因为引用行没有复制。 另一方面，当用户登录时，我们将必须找到所有引用的单位，战斗，物品和位置，以使用完整的用户对象进行响应。

选项3与选项2相反，在选项2中，用户表的mongoIds保留在其他表中。 此选项对我的吸引力不大。

我真的很感激有人可以指导我或提出更好的模型。

编辑：

基本上，这是一个mmorpg游戏，其中多个客户端应用程序将通过Web服务连接到服务器。 我们在客户端有一个本地数据库来存储数据。 我想要一个模型，服务器可以通过该模型来响应完整的用户对象，然后更新或插入客户端应用程序上更改的数据。

Answer 1

首先，NoSQL 不是一个合适的选择。 在SQL中，几乎每个1：N和M：N关系都以相同的方式建模。 NoSQL的哲学是，数据建模的方式取决于数据及其使用模式。

其次，我同意马克·贝克（Mark Ba​​ker）的观点：缩放很难，并且可以通过放松约束来实现。 这不是技术问题。 我喜欢与MongoDB一起工作，但是出于其他原因（无需编写丑陋的SQL；无需复杂而肿的ORM；等等）

现在，让我们回顾一下您的选项： 选项1复制了比所需更多的数据。 您通常将不得不对某些数据进行非规范化，但绝不能对所有数据进行规范化。 如果是这样，则获取引用的对象会更便宜。

选项2/3，它们非常相似。 这里的关键是：谁在写作？ 您不希望许多客户端具有对同一文档的写访问权，因为这将迫使您使用锁定机制，并且/或者将您自己限制为仅进行修饰符操作。 因此，选项2可能比3好。但是，如果A攻击B，它们也会触发对用户B的写操作，因此您必须确保写操作是安全的。

选项4：部分非规范化：您的用户对象似乎是最重要的，因此如何处理：

user { 
 battles : [ {"Name" : "The battle of foo", "Id" : 4354 }, ... ]
 ...
}

这将使显示用户仪表板等操作变得更加容易，因为您无需了解仪表板中的所有详细信息。 注意：然后将数据结构耦合到演示的细节。

选项5边缘数据。 通常，该关系还需要保存数据：

user {
 battles : [ {"Name" : "The battle of foo", "unitsLost" : 54, "Id" : 34354 }, ... ]
}

在这里， unitsLost特定于用户和战斗，因此数据位于图的边缘。 与战斗的名称相反，此数据未标准化。

选项6链接器集合。 当然，这种“边缘数据”可能会变得巨大，甚至可能需要一个单独的集合（链接器集合）。 这完全消除了访问锁定的问题：

user { 
  "_id" : 3443
}

userBattles {
  userId : 3443,
  battleId : 4354,
  unitsLost : 43,
  itemsWon : [ <some list > ],
  // much more data
}

其中哪一个最好取决于您的应用程序的许多细节。 如果用户点击很多（例如，您有一个细粒度的界面），则可以像选项4或6中那样拆分对象。如果您确实需要一批数据，则部分非规范化将无济于事，因此选项2是更可取的。 请记住多重作者问题。

Answer 2

选项2是解决之道。

如果要在某个时间点（必须开始水平扩展）在RDB中进行操作，则还需要开始删除SQL联接并在应用程序级别联接数据。

甚至10gen也建议使用“手动”参考ID： http : //www.mongodb.org/display/DOCS/Database+References