编程:何时选择SQL和何时选择NoSQL?

作为开发人员，我们可能倾向于快速切换。例如，当使用图形时，我们很想使用Neo4j，它实现了很棒的Cypher查询语言。使用JSON时，我们很乐意使用诸如Couchbase之类的东西，该东西实现了有趣的N1QL查询语言。这两种查询语言都受到SQL的极大启发，我认为这是明智的供应商选择（与MongoDB基于JSON的怪异查询语言相对），因为终，SQL语言仍然是当时功能强大，受欢迎的4GL。曾经创造。

但是作为开发人员，我们不应该轻易做出这个决定。是的，起初，这些专用数据库似乎更合适。但是，运营团队维护，监视，修补，调整生产系统的额外成本一定不能被低估。在RDBMS生态系统中甚至如此。近一个的例子是Uber从PostgreSQL切换（返回！）到MySQL：

请注意，他们之前只是反悔，只是为了后悔。事实是，有很多原因使您的运营团队倾向于始终使用相同的数据库，即使这在许可方面非常昂贵。但是，在许多情况下，以下操作的成本甚至更高：

• 与新的数据库供应商签订额外的许可和/或支持合同
• 为新技术找到熟练的DBA（利基数据库可能很难做到）
• 维护两个数据孤岛，并可能维持保持它们同步的成本

终，有一个阈值：

通常，有一个阈值。在达到该阈值之前，请坚持使用RDBMS。在某些时候，请同时考虑或完全迁移。

就在数据库中使用JSON而言，这很简单：

• 偶尔的JSON存储：坚持使用RDBMS。
• 一切都是JSON：也许不是RDBMS。

图形问题也是如此。SQL可以完全处理图形，并使用递归SQL遍历它们。这是一个时髦的语句，用于递归计算子集和问题：

如果您只需要计算几个树/图遍历（例如，对于简单的菜单结构），则不要马上使用RDBMS。如果图形是您的事，而这就是您要做的一切，那么RDBMS可能不是正确的选择。

结论

无论您要解决什么问题。请记住。是的，您所拥有的只是一把锤子，每一个问题开始看起来像钉子。但是，请不要将RDBMS视为愚蠢的锤子。这是一个非常强大的锤子，在2016年，它可以很好地处理很多非关系利基的事情。

对于各种数据问题，RDBMS仍然是佳的默认选择。仅当您超过某个阈值时（或者如果可以预见的话），那么您应该寻找替代方法。因为当您走出利基市场（JSON，图表等）回到“普通”关系业务时，这些选择将使您更加艰难。

后，开发这么多年我也总结了一套学习Java的资料与面试题，如果你在技术上面想提升自己的话，可以关注我，私信发送领取资料或者在评论区留下自己的联系方式，有时间记得帮我点下转发让跟多的人看到哦。