这是一个两部分的问题，所以欢迎任何一方的建议。我也在使用PostgreSQL。
问题1 所以我已经阅读了一些有关我正在处理的项目的约束的命名约定的线程。从它处于早期阶段，我想说得对。
我注意到这里的大多数人（和其他来源）建议按照fk_activetable_referencedtable_fieldname的方式做一些事情。例如，如果我有两个表，一个名为user，另一个名为posts。 post表上转到user table和id字段的外键可能看起来像fk_posts_user_id。
我在想，更好的选择是fk_referencedtable_fieldname_activetable。这样，在某种意义上，它将遵循与顺序命名事物类似的模式，例如fk_user_id1，fk_user_id2等;而不是在最后它将是1,2,3,4，结束将表示外键所在的表。因此，使用上面的示例，我的外键将命名为fk_user_id_post。目前通过这种方式命名它可以更容易地看到我所有的主键外键，但如果有更好的理由以不同的方式进行操作，那么它不是世界末日。
这样做有什么缺点吗？
问题2 如何处理假设您有一个表，其中前三列是不同表上同一主键的所有外键的情况？
使用与上面相同的示例，如果您有一个usertree表，其中第一列（名为user_id）从id表中标识了user，第二列（名为user_pid）也与user表一起转到同一主键，但是存储父用户的值。遵循与上一个（名为user_rid）相同约定的最后一列存储层次结构中顶级父级的值。
目前，我不确定是否更好地制作名称为fk_user_id_usertree的外键（因为它们在技术上都引用了用户表，id字段）或类似{ {1}}我认为这会增加字符，并且可能会使用不那么短的字段来达到字符限制。
不幸的是，我没有丰富的SQL经验，所以我很感激任何人都能提供给我的见解。
答案 0 :(得分：0)
关于第一个问题：
我真的不再生成我的外键名称，因为我的框架现在为我做了。但这是我使用的约定和许多生成器在后端框架上使用的约定。例如，我见过两种类型的约定。假设您有两个表Users和Cars，那么其中的外键将是：
前 - ＆gt; car_id上定义了user_id，然后：
fk-users-car_id（用户是您要添加FK的表格，car_id是字段）fk-users_cars-car_id（首先是添加FK的表，第二个是引用的表，然后是外键）索引：
关于第二个问题：
我会为每个字段添加一个外键，并遵循上述约定之一。外键如下：
fk_user_id_usertree
fk_user_pid_usertree
fk_user_rid_usertree
关于不同方言的一些惯例：
FK_ForeignKeyTable_PrimaryKeyTable fk_[referencing table name]_[referenced table name]_[referencing field name]
对于Postgres，您可以查看 - ＆gt; ADD table_constraint
Postgres constraint documentation
此表单使用与语法相同的语法为表添加新约束 创建表