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

--Example SQL

CREATE TABLE D001_Students
(
    StudentID INTEGER CONSTRAINT nnD001_STID NOT NULL,
    ChristianName NVARCHAR(255) CONSTRAINT nnD001_CHNA NOT NULL,
    Surname NVARCHAR(255) CONSTRAINT nnD001_SURN NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(StudentID)
);

CREATE INDEX idxD001_STID on D001_Students;

CREATE TABLE D002_Classes
(
    ClassID INTEGER CONSTRAINT nnD002_CLID NOT NULL,
    StudentID INTEGER CONSTRAINT nnD002_STID NOT NULL,
    ClassName NVARCHAR(255) CONSTRAINT nnD002_CLNA NOT NULL,
    CONSTRAINT pkD001 PRIMARY KEY(ClassID, StudentID),
    CONSTRAINT fkD001_STID FOREIGN KEY(StudentID) 
        REFERENCES D001_Students(StudentID)
);

CREATE INDEX idxD002_CLID on D002_Classes;

CREATE VIEW V001_StudentClasses
(
    SELECT
        D001.ChristianName,
        D001.Surname,
        D002.ClassName
    FROM
        D001_Students D001
            INNER JOIN
        D002_Classes D002
            ON
        D001.StudentID = D002.StudentID
);

这些是我学到的惯例，但是您应该适应您的开发软管使用的任何东西。

复数。它是实体的集合。 是的。属性是一个实体的单一属性的表示。 是的，前缀表名允许轻松跟踪所有约束索引和表别名的命名。 表和列名用大小写，索引和约束用前缀+ ALL大写。

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

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

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

我的观点是:

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

我不认为有任何一套绝对的指导方针。

只要你在应用程序或数据库中选择的是一致的，我不认为这真的很重要。

我知道这有点晚了，这个问题已经得到了很好的回答，但我想就#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%';