我应该使用 mySQL 还是 MongoDB [关闭]

目前有很多关于 NoSQL 的讨论，据我了解，Mongodb 就是其中之一，对我来说，NoSQL 似乎是 SQL，只是与我们所知道的 mySQL 不同。

可以这样想，它们都存储数据，一个通过具有所谓限制的固定数据库来存储数据，而另一个则在它认为存储数据的最佳时间并且可能没有限制或很少的情况下存储数据。

然而，这对于正在进行转换或考虑进行转换的 Web 开发人员来说是令人困惑的。就我而言，我在一家大型电信公司工作，像这样的转换是需要真正考虑的事情，我们不能依赖于没有物理存在的东西。

也许我没有理解NoSQL的含义，也许我的意思是正确的。

我目前正在重写我们使用的整个 CMS，并且很高兴知道我应该花时间查看 noSQL 还是保留 MySQL（目前似乎没有任何问题）

我们的客户详细信息中只有 5000 行，而备份中有 14000 行，它会被备份，以防万一主表决定搞砸。

您是否被迫选择其中之一？如果不是，为什么要通过必须做“这个”或必须做“那个”来限制解决业务需求的潜在解决方案。我将软件工程的工作流程步骤等同于医生的工作流程步骤。

医生必须做出许多决定才能确保手术成功。这包括诊断、确定切口点以及选择其行业所需的工具；手术刀、骨锯等来完成手术。如果你告诉医生只能用弩来做手术，那么最终的结果对病人或医生来说都不会很好（医疗事故）。

因此，远离笨拙的类比，以下是我选择同时使用两者的几个原因（以在线书店为例）：

• ISBN、作者姓名、出版日期等图书数据存储在 RDBMS（假设为 MySQL）中。通过将此类数据存储在 MySQL 中，我可以运行任意数量的查询来呈现给用户。例如，我可以运行一个查询，返回姓氏带有字母 Z、出版日期为 2005 年的作者出版的所有书籍，按 ISBN 降序排列。在为您的公司（或客户）创建有用的功能时，这种类型的数据操作至关重要。

• 书籍资产（例如封面艺术）使用 NoSQL 解决方案存储在文件系统上。这解决了两个问题。首先，我不希望大量数据使我的 MySQL 数据库（blob）膨胀，因此我将这些数据存储在文件系统上。其次，书籍的封面艺术与任何实际的书籍数据无关（人们真的希望所有书籍的封面艺术都是蓝色的吗？）。我们根本不能放弃一本书的封面艺术，因为当用户浏览我们的在线库存时，它可能会决定销售的成败。

最后，我向您的建议是选择成功完成操作所需的任何和所有工具，并以一种便于将来添加新功能的方式。