我目前正在建模数据库模式。其中，地址被多次使用，遵循固定的结构。在我们以前的系统中，地址关系被建模为地址包含外键，例如用户的外键。
推理：这样，一个地址只能附加到一个父级。然而，从我的角度来看，这绝对是一个混乱，因为有时地址关系中最多存在八个外键，因此必须注意只有一个被填充。
将密钥放在父节点上不是更有意义吗，这样通过非零约束可以确保每个父节点都有一个地址并且地址关系是干净的？父母也很少/从不从地址侧导航到。
还是我这样做违反了任何约定？在这种情况下，清洁不比“公约”更重要吗？如果需要，还可以另外使用触发器对先前的需求进行建模吗？
当前方法：约束以确保在地址上仅设置一个 FK。
我的方法： address_id 作为父母的 FK。
我已阅读以下文章如何有效地建模数据库中的继承？关于数据库中的继承。不幸的是，我在 Packt 的 PostgreSQL 书籍中找不到任何东西。现在我有点困惑，如果我的方法是矫枉过正，甚至不属于数据库或有意义（见最后我的考虑）。
首先，我想使用Table-Per-Concrete来实现以下示例。但是后来我读了几次，你应该只在你真的有性能问题时才这样做，并且只要你没有性能问题，就应该使用每种类型的表。
所以给出以下关系：
system_user (system_user_id, type, first_name, last_name, ...)
user (system_user_id) *Has no unique attributes but special relations accessible only for him, e.g. orders
customer (system_user_id, company_name, ...)
supporter (system_user_id, nickname, ...)
到目前为止一切顺利，但我想知道如何在上面的示例中确保：
我的考虑：
这有意义吗？还是我走错了路？这甚至有必要吗？我应该直接为每个实体创建一个单独的关系吗？
也许我对它有太多的面向对象软件开发人员的看法。非常感谢你的回答。
PostgreSQL 在事务级别有变量吗？如果没有，是否有可能相对容易地实现类似的东西？不幸的是，我对 PostgreSQL 仍然相对缺乏经验，并且只发现您可以在会话级别定义设置。
我目前正在尝试直接在 PostgreSQL 中实现 Hibernate 的历史记录。他们不知道 Hibernate 的简短信息：Hibernate 有一个修订表。它包含一个ID、时间和其他信息。每个表都有一个“_AUD”表。同一事务中的每个更改都会获得相同的修订 ID。
要直接在 PostgreSQL 中实现这一点，我需要一个可以在事务中使用且其值只能在同一事务中使用的变量。我的想法是，每次对交易进行历史记录时，一个函数都会查询该交易的 ID 是否存在，如果不存在，则创建一个，否则返回已经创建的 ID。
我使用最新的 PostgreSQL 版本。