每当我设计数据库时，我总是想知道是否有一种最好的方法来命名数据库中的项目。我经常问自己以下问题:
表名应该是复数吗? 列名应该是单数吗? 我应该为表或列添加前缀吗? 我应该在命名项目时使用大小写吗?
是否有推荐的指导原则来命名数据库中的项?
当前回答
我也支持ISO/IEC 11179风格的命名约定，指出它们是指导方针而不是规定。
参见维基百科上的数据元素名称:
表是实体的集合，并遵循集合命名准则。理想情况下，使用一个集合名称。、人员。复数形式也是正确的:Employees。不正确的名称包括:Employee、tblEmployee和EmployeeTable。”
与往常一样，规则也有例外，例如，一个总是只有一行的表可能用一个奇异的名字更好，例如配置表。一致性是最重要的:检查你的购物是否有惯例，如果有，就遵守它;如果你不喜欢它，那就做一个商业案例来改变它，而不是做一个独行侠。
其他回答
我的观点是:
1)不，表名应该是单数。
虽然对于简单的选择(select * from Orders)似乎有意义，但对于OO等效(Orders x = new Orders)则没有意义。
数据库中的表实际上是该实体的集合，当你使用set-logic时，它更有意义:
select Orders.*
from Orders inner join Products
on Orders.Key = Products.Key
最后一行，连接的实际逻辑，看起来与复数表名混淆。
我不确定是否总是使用别名(如Matt建议的那样)可以消除这种情况。
2)它们应该是单数，因为它们只拥有一种属性
3)如果列名有歧义(如上所述，它们都有一个名为[Key]的列)，表名(或其别名)永远不能很好地区分它们。您希望查询能够快速键入，并且简单-前缀会增加不必要的复杂性。
4)无论你想要什么，我都推荐CapitalCase
我不认为有任何一套绝对的指导方针。
只要你在应用程序或数据库中选择的是一致的，我不认为这真的很重要。
表名一定要保持单数，person而不是people 我也一样 不。我见过一些糟糕的前缀，以至于声明我们处理的是一个表(tbl_)或一个用户存储过程(usp_)。后面跟着数据库名…不要这样做! 是的。我倾向于PascalCase我所有的表名
表名:它应该是单数，因为它是一个表示真实世界对象的单数实体，而不是表示对象的单数实体。
列名:它应该是单数，只有这样它才表示它将持有一个原子值，并将确认归一化理论。然而，如果有n个相同类型的属性，那么它们应该以1,2，…作为后缀。n，等等。
表/列前缀:这是一个巨大的主题，将在后面讨论。
外壳:应该是驼色的
我的朋友Patrick Karcher，我请求你不要写任何可能冒犯别人的东西，就像你写的那样，“此外，外键必须在不同的表中一致命名。如果有人不这样做，殴打他应该是合法的。”我从来没有犯过这样的错误，我的朋友帕特里克，但我写一般。如果他们一起打算为此揍你呢?：）
表名为单数。假设您正在建模某人与其地址之间的关系。 例如，如果您正在读取一个数据模型，您会选择 每个人可以住在0、1或多个地址。”或 每个人可以住在0、1或多个地址。 我认为用复数的称呼比把人写成person更容易。加上集合名词通常与单数名词不同。
我在一个有三个dba的数据库支持团队工作，我们考虑的选项是:
任何命名标准都比没有标准好。 没有“唯一正确”的标准，我们都有自己的偏好 如果有现成的标准，就使用它。不要创建新的标准，也不要混淆现有标准。
我们对表使用单数名称。表往往以系统名称(或其首字母缩写)作为前缀。如果系统复杂，这是有用的，因为您可以更改前缀来将表逻辑地分组在一起。Reg_customer, reg_booking和regadmin_limits)。
对于字段，我们希望字段名包括表的前缀/acryonm(即cust_address1)，我们也更喜欢使用一组标准的后缀(_id表示PK， _cd表示“code”，_nm表示“name”，_nb表示“number”，_dt表示“Date”)。
“外键”字段的名称应与“主键”字段保持一致。
即。
SELECT cust_nm, cust_add1, booking_dt
FROM reg_customer
INNER JOIN reg_booking
ON reg_customer.cust_id = reg_booking.cust_id
在开发新项目时，我建议你写出所有首选的实体名称、前缀和首字母缩写，并将此文档交给开发人员。然后，当他们决定创建一个新表时，他们可以引用文档，而不是“猜测”表和字段应该被称为什么。
