我的团队害怕带有外键关系的关系数据库实体，我不明白为什么

我刚从大学毕业，所以对关系数据库的熟悉程度大部分来自于我的数据库课程，在该课程中，BCNF或3NF以外的任何事物都是荒唐的。当然，这是极端的目的，但是我的工作团队似乎确实将其推向了另一端。

在我们的微服务数据库架构中，实体很少有多个表。您通常会标准化到另一个表的所有内容都存储在json列中。如果以后发现需要查询此json中的属性之一，则会添加一个新列，并将数据存储在两个位置（是的，在同一表的两个不同列中）。

在许多情况下，这些json列绝对具有优势。如果您不需要查询数据，也不必单方面更改数据（这显然是您无法预测的），那么这不是一个坏主意。再加上我们的许多服务都看不到服务器，或者托管在具有淫秽磁盘空间的计算机上，无法满足他们的需求，因此数据复制不是一个大问题。（尽管我通常会出于哲学目的避免这种情况）

当前，我们正在构建一个服务，该服务根据规则所拥有的一组条件匹配规则，然后在规则为真（例如，所有条件都为真）时执行与这些规则关联的一组操作。我的最直接构建此服务的小组认为，从架构规则中规范动作和条件有很大的好处。显然，这些表与规则ID保持外键关系。从我们的角度来看，我们可以避免条件上的数据重复，这使我们能够确保仅对它们进行一次评估，并且在需要它们时很容易找到我们需要的条件和规则，而无需提取每个规则并在内存中进行搜索。

今天，他与我们的一位首席工程师交谈，试图使我远离这种模式。试图以各种方式争辩我们实际上并不需要它，这将在将来引起性能问题，并引用了我们拥有的旧单片，这是设计上的麻烦。他将我们正在做的事情称为“旧方法”，将带有json的平面表称为“新方法”。他争辩说，在我想要原子性的地方，我们不需要它，而不是查询，我们应该在内存中做更多的事情。这是我们许多服务现在遵循的设计原则。我们预计数据量不会大幅增长，这将使我们的查询保持快速。我们确实期望在规则评估和执行操作上花费大量时间。

我知道非关系数据库近年来已经变得越来越流行，但是即使在积极地搜索有关外键关系对性能的影响的信息时，我也看不到很多信息可以证明他的观点。我想他们可能会倾向于引入可能导致问题的大型事务，但这似乎是一个独立于外键本身的问题。

这是我的天真吗？还是我和我的子团队确实缺少某些东西？我没有明确提供有关我们问题的详细信息，因为我不一定正在寻找解决方案。考虑到这是我们大型团队的共同趋势，我真的很好奇他们是否对此有所帮助。

了解您的团队来自何处的关键词是“微服务”。值得首先阅读该概念，尤其是以下信息：

• 应该如何存储数据？
• 设计原则？
• 它们是如何设计规模的？

与任何相对较新的处理方式一样（在软件体系结构方面，相对而言5至10年是相对较新的），您会发现理想和现实有所不同。

理想之一是每个微服务都应拥有自己的数据存储。 注意：我说的是数据存储，而不是数据库。在某些情况下，您只需要搜索引擎，blob存储或简单的缓存（而不是常规数据库）。根据与您交谈的人的不同，理想情况甚至可能进入每个微服务实例的数据存储！

最重要的是，当您谈论要进行互联网扩展时，当您在一个数据库中拥有数百万个用户时，ACID（原子性，一致性，隔离性和持久性）事务的安全性和熟悉性就不会扩展。随着NoSQL的出现，范式已更多地转向BASE（基本可用，软状态，最终一致性）。（参考）

更改PH数据管理方式的影响：

• 数据库现在要处理的事情现在必须用代码进行管理
• 通过在问题上抛出更多的微服务实例，比向服务器添加“无限”资源要容易得多
• 您以增加复杂性为代价来提高可靠性

我无法回答您团队的细节或他们打算解决方案的规模，但是通常您不必拥有全部解决方案或没有解决方案。我不会坐在这里来判断团队是否做出了正确的选择。我只是为您提供一些背景信息，以便您至少可以了解它们的来源。

好的，不是项目的首席工程师，您实际上必须遵循他的指导进行该项目。

我鼓励您完成自己的系统设计并在家里进行原型设计，以便您了解所有折衷方案。这样做是为了您自己的教育，只有在您可以演示工作示例时才在工作中提及。

我的经验是，有人声称约束会导致数据库性能下降。是的，它将必须检查这些约束。但是，当数据库不一致时，这是一个更大的问题，这将导致您编写SQL和更多代码来进行补偿，这通常会增加系统的复杂性并减慢其运行速度。

3nf，如果做得适当，将使数据库更快，因为可以存储更多的冗余数据，因此可以缓存更多的数据库。但是，在您当前的工作中，可能没有足够大的数据集来实际看到规范化数据库和非规范化数据库之间的性能差异。

我认为他们害怕重新创建以前的旧“ travesty”，而不是参照完整性本身。

他辩称，在我想要原子性的地方，我们不需要它。

如果您可以为需要原子性提出可靠的理由（又称非功能性需求），那么他们将需要一个很好的，可靠的抗辩理由，以摆脱提供原子性的麻烦。

...而不是查询，我们应该在内存中做更多的事情。这是一个设计原则。我们预计数据量不会大幅增长。

我们希望你是对的。我建议依靠数据保持“足够小”以保持性能是有风险的。

另外，这些规则的变化率是多少？重复次数越多，您浪费在多个地方的同一件事的时间（也就是金钱）就越多。

RDBMS背后的关键概念已有40多年的历史了。那时的存储非常昂贵，并且任何形式的冗余都被拒绝了。尽管RDBMS背后的概念仍然是正确的，但近几十年来，为提高性能（减少连接）而对非规范化的想法已广为接受。

因此，对于给定大小的RDBMS，通常具有用于性能的逻辑设计（无冗余）和物理设计（有冗余）。

快进到当今存储价格便宜，处理器比以往更快的今天，其中一些设计压力并不是那么重要。归根结底，这是关于您是否关心冗余和孤立记录的判断。对于银行等某些行业，数据正确性至关重要，因此很难看出它们将如何脱离RDBMS。对于其他行业，新的参与者一直在进入市场，因此选择众多。

至于您的团队是否对RDBMS可能带来的限制感到不舒服-谁知道？当然，我看到的初级开发人员并没有像上一代开发人员那样具有RDBMS特质，但这可能与开发人员技术和数据库平台的泛滥有关。

开发人员可以学习的技术无止境，因此很难为您的职业做好正确的准备。当然，开发人员成为所有行业的佼佼者的时代已经过去了-人们可以学到太多。

但是-在手的问题。自己承认，您不会期望数据量增加并且系统运行良好。对于您来说，推销重新设计事物而没有明显好处的想法将是一个很大的负担。或许，如果你可以做一个概念验证，其中一个RDBMS的做法也获得好处，这将是一个不同的故事。

这取决于您使用的数据库。

在传统的RDBMS中，您是对的。数据重复是可憎的。列和它们的json等价性将不可避免地不同步，因为没有什么可强制执行的。外键支持是众所周知的，在描述和加强关系方面做得很好。原子性对于处理几乎所有数据都是至关重要的。

在nosql设置中，它不太清楚。由于没有牢固的关系，关系的执行变得不那么重要。带有列索引的json内容在这些系统上更为常见，因为没有关系意味着它不太可能不同步。而且原子性仅限于单个表，因为这就是nosql的工作方式。

哪个更好取决于您的实际工作和实际需要。

但这听起来好像您的同事在从事货运活动。他们被旧的坏东西咬伤了，所以现在东西必须是新的东西。几年后，一旦被新事物所困扰，他们有望认识到SQL vs noSQL是一组折衷方案。

但是他们不会。希望你会的。