好吧，既然我们有意见:

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

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

SELECT person.Name
FROM People person

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

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

在我看来:

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

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

我们的偏好:

Should table names be plural? Never. The arguments for it being a collection make sense, but you never know what the table is going to contain (0,1 or many items). Plural rules make the naming unnecessarily complicated. 1 House, 2 houses, mouse vs mice, person vs people, and we haven't even looked at any other languages. Update person set property = 'value' acts on each person in the table. Select * from person where person.name = 'Greg' returns a collection/rowset of person rows. Should column names be singular? Usually, yes, except where you are breaking normalisation rules. Should I prefix tables or columns? Mostly a platform preference. We prefer to prefix columns with the table name. We don't prefix tables, but we do prefix views (v_) and stored_procedures (sp_ or f_ (function)). That helps people who want to try to upday v_person.age which is actually a calculated field in a view (which can't be UPDATEd anyway). It is also a great way to avoid keyword collision (delivery.from breaks, but delivery_from does not). It does make the code more verbose, but often aids in readability. bob = new person() bob.person_name = 'Bob' bob.person_dob = '1958-12-21' ... is very readable and explicit. This can get out of hand though: customer.customer_customer_type_id indicates a relationship between customer and the customer_type table, indicates the primary key on the customer_type table (customer_type_id) and if you ever see 'customer_customer_type_id' whilst debugging a query, you know instantly where it is from (customer table). or where you have a M-M relationship between customer_type and customer_category (only certain types are available to certain categories) customer_category_customer_type_id ... is a little (!) on the long side. Should I use any case in naming items? Yes - lower case :), with underscores. These are very readable and cross platform. Together with 3 above it also makes sense. Most of these are preferences though. - As long as you are consistent, it should be predictable for anyone that has to read it.

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

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

以下是我的回答:

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

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

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

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

我也支持ISO/IEC 11179风格的命名约定，指出它们是指导方针而不是规定。

参见维基百科上的数据元素名称:

表是实体的集合，并遵循集合命名准则。理想情况下，使用一个集合名称。、人员。复数形式也是正确的:Employees。不正确的名称包括:Employee、tblEmployee和EmployeeTable。”

与往常一样，规则也有例外，例如，一个总是只有一行的表可能用一个奇异的名字更好，例如配置表。一致性是最重要的:检查你的购物是否有惯例，如果有，就遵守它;如果你不喜欢它，那就做一个商业案例来改变它，而不是做一个独行侠。

这里有一个链接，提供了一些选择。我正在寻找一个简单的规范，我可以遵循，而不是依赖于一个部分定义的规范。

http://justinsomnia.org/writings/naming_conventions.html