有些人做架构决策的时候纯粹是基于谁的声音大:
@xeraa@lukaseder不，我们最重要的架构决策是基于#tweets.这是一个面向Twitter的体系结构。
—加里斯维斯特恩(@gareth)2016年9月21日
然而对其他大多数人而言，决策并不是这么简单。例如：什么时候我们应该启用NoSQL存储系统来代替关系型数据库管理系统（RDBMS）？
关系型数据库（RDBMS）能够适应所有情况
这个问题很明显，假设你开始就使用关系型数据库（RDBMS)，这种传统的数据库系统能够解决任何问题且不容易被取代。这意味着什么？简单的举例：
· 关系型数据库（RDBMS）一直被使用，所以他们和”新来者“相比在市场上有巨大的优势，“新来者”缺少优秀的工具，如社区、支持也不够成熟。
· 埃德加·弗兰克·科德的工作对我们整个行业产生的最大影响可能就是，自那以后，几乎没有像关系模型那样具有革命性的东西了。对一个替代型数据库来说，它很难被普遍使用。意即它们通常被用来解决小问题。
有人会这么说,有时候你确实碰到一个小问题。例如，一个图形数据库的问题。然而事实上，图表和你在关系模型中所标识的东西没有什么根本性的不同。它很容易用多到多的关系表来模拟一个图。
这些同样使用于数据库中的XML/JSON(别忘记，JSON就是XML，但比XML少一些语法和属性，所以它更棒)。有时候，您需要在数据库中的层次结构中存储文档的结构（层次结构数据）而不是规范他们。当然你也可以先规范文档，但可能会做很大的无用功。
大多数现代关系型数据库提供XML/JSON数据结构来存储（以及更重要的查询）数据，包括PostgreSQL、Oracle、DB2、SQLServer等。
那么，我们什么时候决定切换?
作为开发人员，我们倾向于能够快速的切换。例如，当我们处理图形时，我们喜欢用Neo4j，因为它具有不起的数字查询语言。当我们使用JSON时，我们喜欢用Couchbase,因为它实现了有趣的N1QL查询语言。这两种语言都深受SQL查询语言影响，在我看来我们的供应商会给我们提供明智的选择（不会像MongoDB基于JSON查询语言），终究原因，SQL语言乃是由最强大和最流行的4GL曾经创造的。
但是作为开发人员，我们不应该轻率的做出决定。首先，虽然这些专业的数据库看起来像是更好的选择，但是运营团队需要增加额外的维护成本、监控、补丁以及生产系统的额外调整。这在关系型数据库中真实的存在，最近的一个突出的例子是Uber从PostgreSQL切换回MySQL:
https://eng.uber.com/mysql-migration
然而唯一令人遗憾的是他们切换方式和以前相反，这点请注意。事实上你的团队总是喜欢使用相同的数据库有很多的原因，即使是这些数据库团队开发许可很贵，在很多案例里更贵：
· 从事额外的许可和/或合同需要新数据库供应商提供技术支持.
· 为了新技术寻找技能熟练的数据库管理员（DBA）(能够胜任新数据库).
· 维护两个数据仓库，并能维持数据同步的成本。
最终，有一个临界值:
@gareth@xeraa一般情况下，都有一个临界值，没到临界点，可以坚持使用关系型数据库（RDBMS），在某种程度上就要开始考虑同时使用两种数据库或者完全迁移到另一个上。
—卢卡斯埃德尔(@lukaseder)2016年9月21日
在数据库中使用JSON,这很简单：
· 偶尔使用JSON存储：坚持使用关系型数据库（RDBMS）。
· 一切以JSON为主：可以考虑不用关系型数据库(RDBMS）。
这个同样适用于图形问题。SQL完全能够处理图形和递归遍历。递归的计算子集之和，这是一个时髦的声明：
如果你只有一点树形/图形遍历需要计算（例如，一个简单的菜单结构）,就无需涉及关系型数据库。如果图形存储是您的主要业务，那么关系型数据库可能不是一个好的选择。
结论
无论你要解决什么问题，请记住：如果你有一把锤子，而每一个问题开始的时候都可以当作钉子。但不要把关系型数据库当作是把愚蠢的锤子。不要小看它，在2016年它在处理非关系型小众的事情上做的非常的好。
关系型数据库仍然是处理各种数据问题的最好的选择。只有当你存储超过一定阀值（或者你可以预见到要这么做），那是你应该去寻找替代品来替代它。因为当你去寻找一个新的(JSON，图形等）来改变的时候，要浪费你很多的时间回到你“正常”的关系业务里去。
