我在一个有三个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

在开发新项目时，我建议你写出所有首选的实体名称、前缀和首字母缩写，并将此文档交给开发人员。然后，当他们决定创建一个新表时，他们可以引用文档，而不是“猜测”表和字段应该被称为什么。

在我看来:

表名应该是复数形式。 列名应该是单数。 不。 对于表名和列名，可以选择CamelCase(我的首选)或underscore_separated。

然而，就像上面提到的，任何约定都比没有约定好。无论您选择如何做，都要记录它，以便将来的修改遵循相同的约定。

表名一定要保持单数，person而不是people 我也一样 不。我见过一些糟糕的前缀，以至于声明我们处理的是一个表(tbl_)或一个用户存储过程(usp_)。后面跟着数据库名…不要这样做! 是的。我倾向于PascalCase我所有的表名

我在一个有三个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

在开发新项目时，我建议你写出所有首选的实体名称、前缀和首字母缩写，并将此文档交给开发人员。然后，当他们决定创建一个新表时，他们可以引用文档，而不是“猜测”表和字段应该被称为什么。

不。表应该以它所代表的实体命名。 Person，而不是persons是指记录所代表的人。 同样的事情。列FirstName真的不应该被称为FirstNames。这完全取决于你想用列表示什么。 不。 是的。为清晰起见。如果你需要像“FirstName”这样的列，大小写会让它更容易阅读。

好的。这是我的0.02美元

表名为单数。假设您正在建模某人与其地址之间的关系。 例如，如果您正在读取一个数据模型，您会选择 每个人可以住在0、1或多个地址。”或 每个人可以住在0、1或多个地址。 我认为用复数的称呼比把人写成person更容易。加上集合名词通常与单数名词不同。