SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName

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

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

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

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

好的。这是我的0.02美元

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

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

以下是我的回答:

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

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

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

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

SELECT 
   UserID, FirstName, MiddleInitial, LastName
FROM Users
ORDER BY LastName