好吧，既然我们有意见:

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

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

SELECT person.Name
FROM People person

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

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

在我看来:

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

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

我认为这些问题的最佳答案将由您和您的团队给出。有一个命名约定比命名约定的具体方式重要得多。

因为这个问题没有正确答案，你应该花点时间(但不要太多)选择你自己的习惯——这是重要的部分——坚持它。

当然，寻求一些关于标准的信息是很好的，这就是你要问的，但不要因为你可能得到的不同答案的数量而焦虑或担心:选择一个对你来说更好的答案。

以防万一，以下是我的答案:

是的。表是一组记录，老师或演员，所以…复数。 是的。 我不用它们。 我经常使用的数据库——Firebird——所有内容都是大写的，所以没关系。不管怎样，当我在编程时，我以一种更容易阅读的方式写名字，比如releaseYear。

虽然很晚了，但我仍然想对列前缀发表我的意见

对于使用table_column(或tableColumn)列命名标准，似乎有两个主要的论据，都是基于列名本身在整个数据库中是唯一的这一事实:

1)你不需要一直在你的查询中指定表名和/或列别名

2)你可以很容易地在整个代码中搜索列名

我认为这两种观点都有缺陷。不使用前缀解决这两个问题很简单。以下是我的建议:

在SQL中始终使用表名。例如，总是用table。列而不是列。

它显然解决了2)你现在只需要搜索表。而不是table_column。

But I can hear you scream, how does it solve 1)? It was exactly about avoiding this. Yes, it was, but the solution was horribly flawed. Why? Well, the prefix solution boils down to: To avoid having to specify table.column when there's ambiguity, you name all your columns table_column! But this means you will from now on ALWAYS have to write the column name every time you specify a column. But if you have to do that anyways, what's the benefit over always explicitly writing table.column? Exactly, there is no benefit, it's the exact same number of characters to type.

编辑:是的，我知道用前缀命名列可以强制使用正确的用法，而我的方法依赖于程序员

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

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

以下是我的回答:

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

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

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

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

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