Question

当用户可以选择多个项目并将其添加到可以共享的集合时，我构建项目。直到现在数据库看起来像这样：

enter image description here

我开始考虑使用以下结构将其切换到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://"
    }

问题

是否需要切换到MongoDB，或者Mysql能更好地满足我对这个项目的需求以及为什么？
由于MongoDB不支持联接，实现项目类别的解决方案是什么？请注意，这些项目将按类别编制索引，类别标题将如下所示：＆＃34; Accessoaries＆＃34;。

Answer 1

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

当我们从关系数据库迁移到NoSQL世界时，这种数据复制的想法感觉真的很不舒服。但是在NoSQL中完全可以接受，因为你只是在优化不同的东西。是的，如果您从Items中删除了一个实例，则需要从包含它们的任何Set实例中删除这些副本。

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

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

Answer 2

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

关于你的帖子：

如果您没有从中受益更多，那么使用MongoDB是没有意义的而不是从MySQL，我很确定你没有，考虑到你的榜样。您的架构很简单，很容易映射到关系一，我不认为你会有任何性能问题这里。而这里更重要的是你对关系数据库的体验。
对于联接，您可以对数据进行非规范化或查询它是分开的。

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

2 个答案: