作为开发人员我们可能倾向于赽速切换。例如当使用图形时，我们很想使用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的资料与面试题如果你在技术上面想提升自己的话，可以关注我私信發送领取资料或者在评论区留下自己的联系方式，有时间记得帮我点下转发让跟多的人看到哦

发布了66 篇原创文章 · 获赞 10 · 访问量 1万+