关系或面向文档的数据库将更适合

Question

当用户可以选择多个项目并将它们添加到集合中时，我正在构建一个项目，他可以共享这些项目。到现在数据库是这样的：

我已经开始考虑将其切换到具有以下结构的 MongoDB：

    Sets Collection:
    {
            _id: ObjectId("51e06e788abe12d1070352351"), 
            name: "somename", //name of the set
            uid: "df4naL3_", // shortID for the URL
            createdby: ObjectId("51e06e788abe12d107000001"), //mongoId of the user
            items: {
                    [{
                            _id: ObjectId("51e06e788abe12d1070352351"),
                            category: "Dress",
                            title: "some title",
                            price: "33",
                            image: "someimage.png",
                            buyLink: "http://"
                    }]
            }
    }



    Items Collection:
    {
            _id: ObjectId("51e06e788abe12d1070352351"),
            category: "Dress",
            title: "some title",
            price: "33",
            image: "someimage.png",
            buyLink: "http://"
    }

问题

1. 是否需要切换到 MongoDB，否则 Mysql 会更好地满足我对这个项目的需求，为什么？
2. 既然 MongoDB 不支持连接，那么实现项目类别的解决方案是什么？请注意，项目将按类别编入索引，类别标题将类似于：“附件”。

Answer 1

根据我的经验，关系数据库是大多数解决方案的最佳选择。它们很成熟，查询语法很直观，您可以使用很多工具来加快您的开发过程并确保您的解决方案是健壮的。应该有充分的理由考虑使用 NoSQL 数据库。这不是我不喜欢 NoSQL，我真的喜欢，而且我会在需要时使用它。最常见的原因是复杂的数据架构、性能等。您为什么开始为您的项目考虑 NoSQL？这个问题的答案也是您在此处发布的问题的答案。我建议谷歌搜索“何时使用 mongo”。对我来说，NoSQL 默认不是一个工具，它更像是一个解决特定问题的工具。

关于你的帖子：

1. 如果您不能从中受益更多，那么使用 MongoDB 是没有意义的 比来自 MySQL 的，我很确定你不会，考虑到 你的例子。您的模式很简单，很容易映射到关系 一个，我认为你不会有任何性能问题 这里。在这里更重要的是您使用关系数据库的经验。

2. 对于连接，您必须对数据进行非规范化或查询 分开。

Answer 2

1. Here's a great post on NoSQL DB-design.
2. NoSQL 的一个含义是反规范化是可以的。您正在以牺牲存储空间为代价优化检索速度。因此，您可以复制所有项目并将它们作为集合实例的子数组插入。或者，您可以在 Set 实例的子数组中插入引用。这将需要 2 个查询（1 个用于获取 id 列表，另一个用于获取与这些 ide 匹配的所有项目。

当我们从关系数据库转移到 NoSQL 世界时，这种数据复制的想法让人感觉非常不舒服。不过，这在 NoSQL 中是完全可以接受的，因为您只是针对不同的东西进行优化。是的，如果你曾经从 Items 中删除了一个实例，你需要从任何拥有它们的 Sets 实例中删除副本。

问题归结为您的应用程序将如何访问数据。如果您经常访问容器及其内容的所有详细信息，那么 NoSQL 可能非常适合。

老实说，您的最终用户可能不会在意，而且在大多数应用程序的负载下，您可能不会注意到执行速度的差异。我的建议是使用您熟悉的内容，直到负载和使用情况决定您开始优化。这是众所周知的好问题之一。