我觉得这个问题可能是一个明智的答案。当我在代码中创建子对象时，父对象存储对子对象的引用。孩子们不了解父母，除非他们有特定的理由存储参考。
对于数据库，相反的是常态。即：您创建了“有许多”东西的东西，并且对父项的引用存储在许多子项中。
所以一般来说，如果我正在编程，我有一个存储在父项中的子项列表。如果我是数据库，我有很多子项目，每个子项目都有父引用，但父母没有引用子项。
这是如何以及为何成功的？这只是任意设计决策成为常态的问题，还是数据存储以一种方式执行它并且代码对象执行另一种方式的性能或逻辑原因？
答案 0 :(得分：3)
不确定这是不是真正的原因，但这是我的观点。
我发现的根本区别在于，在数据库中，每个单元格都被设计为包含一个数据，而且只包含一个数据。孩子可以通过它的PK很容易地引用父母，在那里有效地形成FK。但是，父母如何引用孩子呢？
请记住，在一对多关系中，每个父级可能有一个任意数量的子级，那么父级需要哪种列来保存这些引用？拥有孩子的PK将是无用的，因为你每列只能容纳一个（这将是一对一的）。你不能简单地将一个PK列表放在一个数据库单元中，除非像逗号分隔的字符串那样破坏，但这会破坏FK的目的并消除RMDBS的大部分好处。中间表是一种可能的解决方案，但是您只需将问题转移到另一个地方，因为该表将成为子项，而父项仍然没有对它的引用。
相比之下，OOP语言包含的数据结构可用于在单个属性中存储多个项目：集合。对于那些具有包含对象的属性，该对象包含多个任意数量的子对象引用。关系数据库缺乏这种结构是否有可能使这样的参考。使用普通对象引用也可以将子对象引用（或多对一方）。
答案 1 :(得分：1)
我们的想法是能够在不修改旧内容的情况下向旧内容添加新内容。
假设您有一个名称和地址的客户端，那么您添加了交易。交易不应该修改客户。然后为客户端添加特殊订单等。您不应该为所有这些修改客户端表。
代码应该是一样的。这是oop的核心原理，称为耦合/内聚