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

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

我建议你看看微软的SQL Server样本数据库: https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks

AdventureWorks示例使用了非常清晰和一致的命名约定，它使用模式名组织数据库对象。

表的单数名称 列的单数名称 表前缀的架构名称(例如:SchemeName.TableName) 帕斯卡壳(又称上驼峰壳)

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

好的。这是我的0.02美元

我们的偏好:

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.

好吧，既然我们有意见:

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

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

SELECT person.Name
FROM People person

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

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

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

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

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

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

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