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