表列名称设计

假设我有以下表格：Customer和Staff。表列名称设计

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

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

哪个设计更好呢？

来源

2012-08-01 Edwin

我会亲自挑＃2 - 它有很少冗余和不必要的重复。如果你使用'Customer.ID'，已经清楚你正在处理一个客户 - 不需要在'CusID'列名中重复这个... – 2012-08-01 10:02:17

我强烈建议**不要**使用MixedCase。 SQL本身默认情况下不区分大小写，但DBMS实现可以改变它。如果你坚持使用小写字母（也可能是下划线），迁移到另一个平台将不那么痛苦。另外：避免保留字，关键字和类型名（日期，名称），甚至包括其他平台的名称。 – wildplasser 2012-08-01 10:10:46

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

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

当您查询列时，您需要引用您感兴趣的模式，表和列，除非有一个或多个这些可以推断出来。除非您的查询非常简单，只能引用一个表，否则您需要直接引用表名或使用别名引用表名。来自客户C的Customer.ID或C.ID等

第一个选项是对所有列名的唯一性的技术要求的回退，它适用于旧的ISAM数据库和20世纪60年代的COBOL等语言， 20世纪70年代。这在20世纪80年代被毫无理由地拖入了dBase中，并且在关系和对象DBMS时代已经成为一种惯例。 抵制这个过时的惯例。

第二种方法更简单，更具可读性。更简单，更易读的代码更容易编写，并且更容易维护。

来源

2012-08-01 13:09:20

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

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)

来源

2012-08-01 10:06:33

我个人不喜欢这个。我认为绝对不需要在每个领域重复实体名称。在查询中，您通常会在字段名前使用表名。除非你只有一张桌子，但是重复两次都没有意义。 – 2012-08-01 15:26:21

Thnx队友。也许你是对的。但是，我们正在使用这样的字段名称，而且我们的数据库大多数都有超过100个。的表格。 – 2012-08-02 06:42:55

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

来源

2012-08-01 10:12:57 rmaruszewski

谢谢大家的帮助:) – Edwin 2012-08-02 03:48:04

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

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

所以，我推荐一种混合的方法：

前缀键字段名，让他们所有表中是唯一的，避免任何需要重命名传播领域。
不要在非关键字段名称前面加上短名称，尽管这可能会导致不同表格中的名称重复。

例如：

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

如果你碰巧有两个之间的结合表，它会看起来像这样...

CustomerStaff(CustomerID PK FK1, StaffID PK FK2)

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

他们潜在的多层次！

只是一个例子。是否有道理是另一回事。

来源

2012-08-01 15:19:10

除了个人喜好之外，没有什么特别的理由要有一个命名约定，即外键字段的名称应该等于主键字段的名称。实际上，经常发生的情况是，一个表可能有多个外键指向同一父表，所以有时需要在外键名和主键名之间存在差异。有些人认为，主键名称前面带有表示_harms_可读性的前缀，而不是相反。 – 2012-08-01 18:16:42

@JoelBrown正如我在我的回答中解释的那样，除了个人偏好之外，还有一个原因：通过读取其名称，立即知道特定移植密钥来自何处的能力。至于同一父母的多个FK，这当然不会经常发生（我能想到的一个常见情况是实施DAG），即使它存在一致的重命名方案，以保留名称的“精神”它仍然清楚它来自哪里。至于那些“相信前缀......有害可读性”的人，我希望他们解释_why_？ – 2012-08-01 19:41:18

@BrankoDimitrijevic顺便说一句，NATURAL JOIN和JOIN ... USING可以从相同的名字中受益。 – 2012-08-01 19:46:46

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

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

来源

2012-08-01 15:46:00 HLGEM

“ID”是否是SQL反模式是宗教战争的问题。迷恋自然联结的人认为ID是一种反模式。另一方面，也有其他人认为自然联结是懒惰和草率的，并且是自身的反模式。 – 2012-08-01 18:08:15

我不使用自然连接（SQL Server不允许它们，我也不会，因为我同意它是不好的技术）尽管如此，它是固有的你保护你的数据库通过不使用保证会导致问题的技术，如果一些后来的人在路上确实使用自然连接。这是基本的设计，从不创造太容易被滥用的东西。我也知道这是一个反模式，因为我编写复杂的报表查询，它也会产生问题。 – HLGEM 2012-08-01 18:36:39

我还注意到，我有一位顶级SQl专家写的一篇参考文章，也称之为反模式。 – HLGEM 2012-08-01 18:39:48

表列名称设计

回答

相关问题