将我的思维从关系模型转变为文档存储(理论)

Question

我还在想，像Mongo这样的东西是如何在野外使用的。

有没有人能给我解释一下(我知道这很简单)？

好的，假设我有一组用户，他们有一堆服务，在SQL数据库中，他们将像这样存储：

用户表

| user_id | name | address |
|---------|------|---------|
| 1       | Zen  | 1 a St  |
|---------|------|---------|

服务

| service_id | user_id | service_type | cost |
|------------|---------|--------------|------|
| 1          | 1       | hosting      | 50   |
|------------|---------|--------------|------|

在Mongo中，是否会将其存储在用户中？所以它更像是一个人用对象编程来表示它？

例如：

User: 1
    Name: Zen
    Address: 1 a St
    Services:
        service 1
             type: hosting
             cost: 50

如果是这样的话，是否有一个指向值的“指针”(对于不止一个“事物”可能“拥有”另一个“事物”的情况，或者数据继承具有需要这样做的关系的情况？

考虑到来自SQL背景的Mongo，如何解决这个问题？

谢谢

Answer 1

建模可以或多或少是抽象的。在SQL世界中，表是您可以使用的最低抽象级别，并且仍然将数据与底层主题联系起来。更高级别的抽象是关系建模和ER建模。“更高”不是“更好”的代号。每个抽象级别都通过在其他功能上进行修饰来突出显示某些功能。对您的目的有用的级别取决于您试图看得更清楚的内容。

另一个回复提到Mongo支持嵌套。嵌套可以是对数据项之间的层次关系进行编码的一种方式，而不会强加太多的超结构。但是如果不了解Mongo，我不能告诉你这是否是Mongo的架构师为他们的用户提供嵌套的原因。

层次关系可以是有益的，也可以是阻碍的，这取决于你想要做什么。例如，如果您了解用户，并且您正在尝试查找所有服务，那么所提出的嵌套结构将非常易于使用，并且可能非常高效。但是，如果你知道这项服务，并且你想找到所有的用户，你就会陷入痛苦的世界。

克服层次结构的不幸副作用是关系模型和关系数据库获得认可的主要原因之一。但是等级关系并不总是“坏”的。在某些情况下，这是对数据进行建模的最佳方式。

回到您的问题，您可能希望在更高的抽象级别上比较SQL和Mongo，而不是比较表和嵌套结构。我已经告诉过您在与SQL相关的情况下应该寻找更高层次的抽象。对于Mongo，其他响应者将不得不告诉你同样的事情。

最终，如果您不断提高抽象级别，您应该会找到一个同样适用于SQL和Mongo的模型。

Answer 2

注意:我从未使用过Mongo，但我使用了几个NoSQL解决方案进行开发。

在Redis和CouchDB中，我都使用前缀-后缀样式的命名约定来存储对象。

服务===

services.userid.1

services.userid.2

用户===

users.userid.1

users.userid.2

现在，为用户找到服务应该是轻而易举的事情。=>服务.用户名.通配符

Answer 3

MongoDB中的有效数据建模遵循您的应用程序需求和常见用例。您可以将文档视为类似于序列化对象；MongoDB文档格式支持包括嵌套在内的丰富数据结构。

首先考虑您的应用程序用例，以便计划理想的查询和操作数据的方式，这将是有建设性的。您不必在MongoDB中预先声明您的模式，这对原型设计很有帮助。MongoDB中的模式通常更类似于数据仓库，其中一些数据被有意地反规范化，以避免联接和提高性能。事实上，MongoDB不支持连接或子查询:)。

对于关系，如果您使用对象文档模型或数据映射器，可能还需要考虑一些问题。这些关系的许多提供者帮助器。

传统的选择是是否embed or link相关数据。

对于您的示例，您仍然可以拥有一个users集合和一个services集合：

• 如果用户has_many服务，您可能会将其服务列表作为数组嵌入到用户文档中。
• 用户的服务可能包括基本详细信息，如serviceID和名称；serviceID将是可用于在服务集合中查找完整服务定义的唯一ID。这将链接到服务集合。注意: MongoDB服务器不支持连接，因此如果您想要查找用户和每个服务的完整详细信息，则需要多次查询。

相关阅读：

• Designing MongoDB Schemas with Embedded, Non-Embedded and Bucket Structures
• MongoDB: Schema Design