Jer*_*emy 90 sql database-design naming-conventions
在我们的开发组中,我们就主键和外键的命名约定进行了激烈辩论.我们小组基本上有两种思想流派:
1:
Primary Table (Employee)
Primary Key is called ID
Foreign table (Event)
Foreign key is called EmployeeID
要么
2:
Primary Table (Employee)
Primary Key is called EmployeeID
Foreign table (Event)
Foreign key is called EmployeeID
我不想在任何列中复制表的名称(所以我更喜欢上面的选项1).从概念上讲,它与其他语言中的许多推荐实践一致,在这些实践中,您不在其属性名称中使用对象的名称.我认为命名外键EmployeeID(或Employee_ID可能更好)告诉读者它是表的ID列Employee.
其他一些人更喜欢选项2,您可以在其中命名前缀为表名的主键,以便整个数据库中的列名相同.我明白了这一点,但你现在无法在视觉上区分主键和外键.
此外,我认为在列名中包含表名是多余的,因为如果您将表视为实体而将列视为该实体的属性或属性,则将其视为ID属性,而Employee不是EmployeeID员工的属性.我不去问我的同事他PersonAge或她PersonGender是什么.我问他的年龄是多少.
就像我说的那样,这是一场激烈的争论,我们继续谈论它.我有兴趣获得一些新的观点.
Ste*_*wig 71
如果两个表中的两列具有相同的名称(约定#2),则可以使用SQL中的USING语法来保存一些键入和一些样板噪声:
SELECT name, address, amount
FROM employees JOIN payroll USING (employee_id)
支持约定#2的另一个论点是它是关系模型的设计方式.
通过使用相应域的名称标记每列的重要性来部分地传达.
Rus*_*een 51
这并不重要.我从未遇到过选择1和选择2之间存在真正差异的系统.
杰夫阿特伍德在这个话题上有一篇很棒的文章.基本上人们争论并最激烈地争论那些他们无法证明错误的主题.或者从不同的角度来看,这些话题只能通过基于最后一个人论点的阻挠风格耐力来赢得.
选择一个并告诉他们关注实际影响代码的问题.
编辑:如果你想玩得开心,请让他们详细说明为什么他们的方法优于递归表引用.
KM.*_*KM. 12
我认为这取决于您的应用程序如何组合在一起.如果您使用ORM或设计表来表示对象,那么选项1可能适合您.
我喜欢将数据库编码为自己的图层.我控制一切,应用程序只调用存储过程.结果集具有完整的列名称是很好的,特别是当连接了许多表并返回了许多列时.有了这个应用程序,我喜欢选项2.我真的很想看到列名在连接上匹配.我曾经在他们不匹配的旧系统上工作,这是一场噩梦,
您考虑过以下事项吗？
Primary Table (Employee)
Primary Key is PK_Employee
Foreign table (Event)
Foreign key is called FK_Employee