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

对于使用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.

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

在我看来:

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

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

我总是听到这样的争论，即表格是否多元化完全是个人品味的问题，没有最佳实践。我不相信这是真的，尤其是作为一个程序员而不是DBA。据我所知，除了“这对我来说很有意义，因为它是对象的集合”之外，没有其他合理的理由将表名改为复数形式，而使用单数表名在代码中有合理的好处。例如:

It avoids bugs and mistakes caused by plural ambiguities. Programmers aren't exactly known for their spelling expertise, and pluralizing some words are confusing. For example, does the plural word end in 'es' or just 's'? Is it persons or people? When you work on a project with large teams, this can become an issue. For example, an instance where a team member uses the incorrect method to pluralize a table he creates. By the time I interact with this table, it is used all over in code I don't have access to or would take too long to fix. The result is I have to remember to spell the table wrong every time I use it. Something very similar to this happened to me. The easier you can make it for every member of the team to consistently and easily use the exact, correct table names without errors or having to look up table names all the time, the better. The singular version is much easier to handle in a team environment. If you use the singular version of a table name AND prefix the primary key with the table name, you now have the advantage of easily determining a table name from a primary key or vice versa via code alone. You can be given a variable with a table name in it, concatenate "Id" to the end, and you now have the primary key of the table via code, without having to do an additional query. Or you can cut off "Id" from the end of a primary key to determine a table name via code. If you use "id" without a table name for the primary key, then you cannot via code determine the table name from the primary key. In addition, most people who pluralize table names and prefix PK columns with the table name use the singular version of the table name in the PK (for example statuses and status_id), making it impossible to do this at all. If you make table names singular, you can have them match the class names they represent. Once again, this can simplify code and allow you to do really neat things, like instantiating a class by having nothing but the table name. It also just makes your code more consistent, which leads to... If you make the table name singular, it makes your naming scheme consistent, organized, and easy to maintain in every location. You know that in every instance in your code, whether it's in a column name, as a class name, or as the table name, it's the same exact name. This allows you to do global searches to see everywhere that data is used. When you pluralize a table name, there will be cases where you will use the singular version of that table name (the class it turns into, in the primary key). It just makes sense to not have some instances where your data is referred to as plural and some instances singular.

总而言之，如果你将表名改为复数，那么你就失去了让你的代码更聪明、更容易处理的所有优势。甚至在某些情况下，您必须使用查找表/数组来将表名转换为本可以避免的对象或本地代码名。虽然一开始可能感觉有点奇怪，但单数表名比复数表名具有显著优势，我相信这是最佳实践。

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

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

以下是我的回答:

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

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

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

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

我的观点是:

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

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

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

我们的偏好:

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.