请参阅ISO 11179-5:命名和识别原则 你可以在这里获得:http://metadata-standards.org/11179/#11179-5

我之前写过一篇博文:ISO-11179命名约定

不。表应该以它所代表的实体命名。 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.

请参阅ISO 11179-5:命名和识别原则 你可以在这里获得:http://metadata-standards.org/11179/#11179-5

我之前写过一篇博文:ISO-11179命名约定

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

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

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

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