这个问题适用于所有NoSQL,特别是那里的mongoDB专家。我从一个项目设计关系数据库开始,但客户希望我们使用可轻松扩展的数据库。为了实现这一点,我们决定使用mongoDB。现在,我无法映射NoSQL的关系模型。我有与很多其他表的许多一对多的关系,一个用户表如下图所示:与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>
}
1选项(在用户只外键):
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具有很多重复,因为我们正在添加其他表的完整的行。我在这里看到的一个问题是,如果某个项目或战斗更新了,我们将不得不在用户表中找到它的所有事件并更新它们。但是这给我们带来的好处是始终有一个完整的用户对象,可以在登录时交给客户端应用程序。
选项2更具关系性,我们只有用户表中其他表的mongoIds。这个选项的好处是,更新战斗或物品不会有太多的成本,因为行不被复制。另一方面,当用户登录时,我们将不得不查找所有引用的单位,战斗,项目和位置以用完整的用户对象进行响应。
选项3与选项2相反,其中users表的mongoIds保存在其他表中。这个选项对我没有吸引力。
我真的很感激有人能指导我或想出一个更好的模型。
编辑:
基本上这是一个MMORPG游戏,其中多个客户端应用程序将通过Web服务连接到服务器。我们在客户端有一个本地数据库来存储数据。我想要一个模型,服务器可以通过它完成一个完整的用户对象的响应,然后更新或插入在客户端应用上更改的数据
“更好”是一个目的的问题。这些数据的访问模式是什么? – 2012-01-13 11:05:48
基本上这是一个MMORPG游戏,其中多个客户端应用程序将通过web服务连接到服务器。我们在客户端有一个本地数据库来存储数据。我想要一个模型,通过它服务器可以用一个完整的用户对象进行响应,然后更新或插入在客户端应用程序中更改的数据。 – umair 2012-01-13 11:09:12
关系数据库具有相当的扩展能力...差异应该是它们预期可以保持的数据类型,不是一个虚假的偏见,认为RDB只适用于小数据,mongodb适用于大型 – 2012-01-13 11:09:33