Question

假设我有以下表格：Customer和Staff。

Customer (CusID, CusName, CusAddres, CusGender)
Staff (StaID, StaName, StaAddress, StaGender)

VS

Customer(ID, Name, Address, Gender)
Staff(ID, Name, Address, Gender)

哪种设计更受欢迎？为什么？

Answer 1

SQL采用一种称为域名完整性的概念，这意味着对象的名称具有由其容器给出的范围。

列名必须是唯一的，但仅限于包含列的表的上下文中。表名必须是唯一的，但仅限于包含表等的模式的上下文中。

当您查询列时，您需要引用您感兴趣的架构，表和列，除非可以推断出其中的一个或多个。除非您的查询非常简单，只能引用一个表，否则您需要直接引用表名或使用别名，例如：来自客户C的Customer.ID或C.ID

第一个选项是对所有列名称唯一性的技术要求的回归，这些列名称适用于旧的ISAM数据库以及20世纪60年代和70年代的COBOL等语言。在20世纪80年代，这种情况在没有任何理由的情况下被拖入了dBase，并且已经成为关系和对象DBMS时代的常规。 拒绝这个过时的约定。

第二种方法更简单，更易读。更简单，更易读的代码更易于编写，更易于维护。

Answer 2

键被“传播”到外键，因此如果它们在所有生成的“副本”中保持其名称不变，则它很有用。它只是使数据库模式更清晰：您不必查看FK定义¹以查看特定字段的来源 - 您可以通过浏览其名称来实现。

另一方面，非关键字段不会传播，并且没有特别的理由让它们的名称在各自的表之外保持唯一。

所以，我建议采用混合方法：

前缀键字段名称，以使它们在所有表中保持唯一，并且无需重命名传播的字段。
不要为非关键字段名称添加前缀以使它们更短，即使这可能会导致在不同的表中重复某些名称。

例如：

Customer (CustomerID, Name, Addres, Gender)
Staff (StaffID, Name, Address, Gender)

如果你碰巧在两个²之间有一个联结表，它看起来就像这样......

CustomerStaff(CustomerID PK FK1, StaffID PK FK2)

...所以不需要重命名（如果两个父键都被命名为ID，则必须这样）并且立即清楚CustomerID和StaffID的来源。另外，我个人不喜欢缩短前缀中的表名（因此CustomerID而不是CusID），因为这使得命名更具“机械性”和可预测性。

¹他们可能有多个级别！

²只是一个例子。是否有意义是另一回事。

Answer 3

ID是一个SQL反模式（http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic-Programmers/dp/1934356557/ref=sr_1_1?s=books&ie=UTF8&qid=1343835938&sr = 1-1＆amp; keywords = sql + antipatterns），永远不要命名列ID。我会用：

Customer(CustomerID, Name, Address, Gender) 
Staff(StaffID, Name, Address, Gender)

Answer 4

我会说第二种选择更好。如果您决定更改表名，则不必更改所有列的名称。另外，在编写SELECT语句时，通常也会使用别名（“select sta.name，sta.adress from staff sta ...”）一般来说，如果有疑问，总是选择一个更简单的解决方案。

Answer 5

每个行业都有自己的标准。在那些两种风格的设计都是正常的。建议使用First。

Customer(CusID, CusName, CusAddres, CusGender)
Staff(StaID, StaName, StaAddress, StaGender)

因为它使用的表格符号如Customer到Cus和Staff到Sta。它有助于该项目对维护有益。

某些组织还将vch用于VARCHAR数据类型，int用于INT数据类型。

喜欢

Customer(intCusID, vchCusName, vchCusAddres, vchCusGender)
Staff(intStaID, vchStaName, vchStaAddress, vchStaGender)

表列名称设计

5 个答案: