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

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

命名约定允许开发团队在项目的核心设计可发现性和可维护性。

一个好的命名约定需要时间来发展，但一旦它到位，它就可以让团队使用一种共同的语言向前发展。好的命名约定会随着项目的发展而有机地发展。好的命名约定可以很容易地处理软件生命周期中最长和最重要的阶段(生产中的服务管理)中的变化。

以下是我的回答:

是的，当表名指的是一组交易、证券或交易对手时，表名应该是复数。 是的。 是的。SQL表前缀为tb_，视图前缀为vw_，存储过程前缀为usp_，触发器前缀为tg_，后面加数据库名。 列名应以小写字母用下划线分隔。

命名很难，但在每个组织中都有人可以命名事物，在每个软件团队中都应该有人负责命名标准，并确保像sec_id、sec_value和security_id这样的命名问题在融入项目之前尽早得到解决。

那么，一个好的命名规范和标准的基本原则是什么呢

使用你客户的语言 解域 是描述性的 是一致的 消除歧义，反思和重构 不要使用缩写，除非它们 每个人都清楚 不要使用SQL保留关键字作为 列名

Table names should always be singular, because they represent a set of objects. As you say herd to designate a group of sheep, or flock do designate a group of birds. No need for plural. When a table name is composition of two names and naming convention is in plural it becomes hard to know if the plural name should be the first word or second word or both. It’s the logic – Object.instance, not objects.instance. Or TableName.column, not TableNames.column(s). Microsoft SQL is not case sensitive, it’s easier to read table names, if upper case letters are used, to separate table or column names when they are composed of two or more names.

好吧，既然我们有意见:

我认为表名应该是复数。表是实体的集合(表)。每一行表示一个实体，表表示集合。因此，我将Person实体表称为People(或Persons，随您喜欢)。

对于那些喜欢在查询中看到单一“实体名称”的人来说，这就是我使用表别名的原因:

SELECT person.Name
FROM People person

有点像LINQ的“from person in people select person. name”。

至于2、3和4，我同意@Lars的观点。

我知道这有点晚了，这个问题已经得到了很好的回答，但我想就#3关于列名前缀的问题提出我的看法。

所有列都应该使用一个对定义它们的表唯一的前缀命名。

例如，给定表“customer”和“address”，让我们分别使用前缀“cust”和“addr”。"customer"中会有"cust_id"， "cust_name"等。“address”将包含“addr_id”，“addr_cust_id”(FK返回给客户)，“addr_street”等。

当我第一次看到这个标准时，我坚决反对它;我讨厌这个主意。我无法忍受所有额外的输入和冗余。现在我已经有了足够的经验，我再也不会回去了。

这样做的结果是数据库模式中的所有列都是唯一的。这有一个主要的好处，它压倒了所有反对它的论点(当然，在我看来):

您可以搜索整个代码库，并可靠地找到涉及特定列的每一行代码。

The benefit from #1 is incredibly huge. I can deprecate a column and know exactly what files need to be updated before the column can safely be removed from the schema. I can change the meaning of a column and know exactly what code needs to be refactored. Or I can simply tell if data from a column is even being used in a particular portion of the system. I can't count the number of times this has turned a potentially huge project into a simple one, nor the amount of hours we've saved in development work.

另一个相对较小的好处是，当你进行自连接时，你只需要使用表别名:

SELECT cust_id, cust_name, addr_street, addr_city, addr_state
    FROM customer
        INNER JOIN address ON addr_cust_id = cust_id
    WHERE cust_name LIKE 'J%';

基本数据库命名约定(和样式)(点击这里查看更详细的描述)

表名 选择简短、明确的名字，不要超过一两个单词 容易区分表 方便唯一字段名的命名以及查找和链接表 给表取单数名，而不是复数名(更新:我仍然同意这种惯例的原因，但大多数人真的喜欢复数表名，所以我的立场软化了)…请点击上面的链接