说我有一张桌子people (id, firstname, lastname)。
还有两个表应包含这些字段，因此我们只需重复使用人员表：users (id, username, person_id)和companies (id, name, contact_person_id)。
现在要获得公司或用户，我们必须加入人员表。如果我们更改人员表，我们必须重写所有查询，可能还有很多代码。
这是一个真正的问题吗？我的数据库结构有缺陷吗？是否存在维持低耦合的解决方案，例如ORM？
感谢所有的回答。
答案 0 :(得分：4)
耦合是一个植根于软件模块的概念。
我没有看到与SQL的相关性。
看到两个表都存在于同一个服务器中，它们已经耦合（就使用服务器的软件而言）。我只是看不到你想要实现的低耦合。
来自wikipedia：
在计算机科学中，耦合或依赖是每个程序模块依赖于其他每个模块的程度。
答案 1 :(得分：2)
您的外键可以轻松访问people表中的数据。是的，如果更改people表，可能需要更改，但更改影响您的JOIN的内容意味着您的要求已更改。
换句话说，需要以影响JOIN的方式更改firstname或lastname是不现实的。这不是一个真正的问题。
上面所代表的是Database Normalization的结果，这是常见且良好的做法。通过将您的表视为单独的实体，因为它们很可能与软件的逻辑关系，它确实引入了表之间的耦合，但它的设计实际上是简化和提高可伸缩性。
这是一个很好的数据库设计。
答案 2 :(得分：1)
大多数情况下，所做的修改不会造成破坏，例如添加新列。像修改列名或数据类型这样的改变很难完成。
关系数据库管理系统允许创建特殊数据类型，这使得某些修改变得更加容易。如果将FirstName和LastName定义为用户定义的类型PersonName，则更改类型将使所有使用列的查询和存储过程中出现相同的更改。不幸的是，几乎没有人使用过用户定义的数据类型。
从概念上讲，如果称为“人”的东西是用户和公司事物的一部分，实际上代表了一个连贯的想法，那么对Person的更改将不会具有破坏性，因为任何地方都需要进行任何需要的更改。另一方面，如果为了方便起见，这是在概念上将不同的东西混合在一起，那么你可能会遇到问题。
答案 3 :(得分：1)
现在我们必须获得公司或用户 加入人员表。如果我们改变 人民表，我们必须改写所有 查询，可能还有很多代码。
这是一个真正的问题吗？是我的DB 结构有缺陷？
不，在这种情况下，你的结构没有缺陷。你对它的看法是有缺陷的。
表名和列名构成数据库公共接口的一部分。将其视为API。无论你编写什么样的代码，如果你改变API，你将不得不重写一些代码。如果更改数据库API（表和列名称），则可能必须重写 lot 代码。但是。 。
假设您从版本控制系统中检出数据库代码，并将“people”表中的列名更改为first_name，last_name。没有任何其他更改，您将无法重建数据库，因为您已经破坏了公共接口。 （选择“firstname”的视图将终止构建。读取或写入“firstname”的存储过程将终止构建。）
但您可以通过重命名“人员”表并创建视图来快速恢复。你可以这样前进。
SELECT * FROM persons;）任何期望查询或更新名为“people”的基表的代码都将是查询和更新名为“people”的视图。不需要重写其他代码。 （除非你的代码对于它是否针对基表进行操作做出了无根据的假设。）
关系数据库通过可更新视图实现逻辑数据独立性。