对于数据库表设计,对多对多表(连接表)使用特殊的命名约定是否有好处?

我倾向于遵循这样的模式:

1. Table names are singular nouns
2. Link tables are nouns connected by underscore
3. a synonym can be created for the reverse order of the nouns

例如

ADDRESS
ORGANIZATION
ORGANIZATION_ADDRESS
synonym: ADDRESS_ORGANIZATION

这会简化所有查询的创建,无论您从哪个方向接近连接。 同样重要的是,你要使用完整的单词,避免使用缩写——这会让每个人都更简单。

任何命名约定的主要优点是,它允许不熟悉特定设计的人立即洞察该设计。例如,有充分的理由将国家和语言之间的关系建模为一对一。

美国_____英语
加拿大英语
法国法语

也许我们只对一个国家最常用的语言感兴趣。也有充分的理由将这种关系建模为一对多关系。

美国_____英语
加拿大英语
加拿大法语
法国

如果我看到有三张桌子:

语言文字
国家
语言\国家

我不需要看外键来理解底层设计。将此与:

语言文字
国家
语言-口语或连读-加入或加入002

您还可能发现自己正在编写脚本来自动创建和/或删除索引、外键等。如果脚本能够一致地解析表名,则更容易执行此操作。

优点是您不必发明有趣的名称,并且从两个引用的表中可以明显地看到连接表的名称。

经过多年的各种命名方案的改进,我发现最新的命名方案是最直观的(关于SQL Server):

• 表名为Pascal大小写,不带下划线

• 联接表名称用下划线连接联接表的名称

生成表foo、footype、bar、bartype和footype_bartype和foo bar。

Oracle不提供(方便的)区分大小写的功能,因此您必须找到其他的功能。