谁能推荐TSQL的编码标准？

长期以来，我们已经为.Net代码制定了编码标准，并且随着时间的流逝，似乎有一些声誉卓著的来源来提出如何应用它们的想法。

我希望能够为我们的产品编写用于编写的SQL的一些标准，但是对于确定良好编写的SQL的共识，似乎没有任何资源。

coding-standards sql-server

— 罗兰·肖
source

Pinal Dave在他的网站上列出了编码标准。它们看起来像一套标准的公平基础。

— 将在

关于SO有一个相关的问题。

— Scott Whitlock

@Scott仅涵盖身份识别；关于命名，使用游标/存储过程/数据类型的选择或实际上影响代码质量的任何事情都没有...

— Rowland Shaw

确切地讲，因此为什么我说这是“相关的”而不是“重复的”。

— Scott Whitlock

Answers:

根据我的经验，我要寻找的主要内容是：

表和列的命名-查看是否对ID类型的列使用ID，Reference或Number，名称使用单数还是复数（表名常用的复数-例如THINGS，列名常用的单数-例如THING_ID）。对我来说，最重要的是保持一致性，避免人们浪费时间（例如，您不会碰到有人将THING作为表名的错别字，因为您只凭直觉就知道表名永远不会是单数）。
所有创建的文件都应包含一个放置（取决于存在的对象）的放置。您可能还希望包括授予权限，具体取决于您。
选择，更新，插入和删除应该布置为每行一个列名，一个表名和一个where子句/ order by子句，以便在调试期间可以轻松地将它们一次注释掉。
对象类型的前缀，尤其是在它们可能会混淆的地方（对于视图来说，v是最重要的）。不知道它是否仍然适用，但是对于系统过程以外的存储过程，以sp_开始时效率低下。无论如何，usp_可能是区分它们的最佳实践是我最近使用的方法。
一个标准，指示触发器的名称应包括用于更新/插入/删除的触发器及其适用的表。我没有首选标准，但这是关键信息，必须易于查找。
SQL Server早期版本中的对象所有权或2005年及以后版本中应存在的架构的对象的标准。这是您的电话，但是您永远都不应猜测谁拥有某物/它住的地方），并在可能的情况下将模式/所有者包含在CREATE脚本中，以最大程度地减少错误创建它的可能性。
指示使用SELECT *的任何人都将喝一品脱自己的尿液。
除非有一个非常非常好的理由（不包括您的懒惰），否则从一开始就拥有，执行和维护主键/外键关系。毕竟，这是一个关系数据库，而不是一个平面文件，孤立的记录将使您的支持生活陷入困境。另请注意，如果您现在不这样做，我可以向您保证，您将永远不会在活动结束后实现它，因为一旦获得数据，它的工作量是其工作量的10倍（由于您从未执行过操作，因此可能会有点麻烦）关系正确）。

我敢肯定我错过了一些东西，但是对我来说，它们确实是在很多情况下真正提供真正好处的东西。

但是，与所有标准一样，少即是多。您的编码标准越长，人们阅读和使用它们的可能性就越小。一旦您跳过了几个间隔较大的页面，便开始寻找那些在现实世界中并没有实际改变的东西，因为您只是在减少人们做任何事情的机会。

编辑：两项更正-包括所有权部分中的架构，删除了有关count（*）的错误提示-请参阅以下评论。

— 乔恩·霍普金斯
source

一些奇怪的选择...“ SELECT COUNT（*）”不好吗？听说过架构（与所有者不同）吗？您的其他人也很好

— gbn

@Jon Hopkins-我知道为什么使用SELECT *不好。如果您可以说为什么使用SELECT COUNT（*）不好，那将是很好的。

— 2011年

@gbn @ k25-几年前（2002年？），我有一个DBA的人非常关注计数（*），但是在搜索您的问题时谷歌搜索似乎已经过时了（如果确实如此）。 sqlservercentral.com/articles/Performance+Tuning/adviceoncount / ...（需要注册）。她最初是Oracle DBA，所以那里可能是一个真正的问题，她认为这也是SQL优化程序的问题。

— 乔恩·霍普金斯

@gbn-是的，尽管自引入以来我一直比较放心，所以我的自动反应是用户。我将更新答案以涵盖架构。

— 乔恩·霍普金斯

@ gbn，@ k25-进一步挖掘count（*）。显然，这是Oracle 7及更早版本中的一个问题，已在8i及更高版本中修复。尚不清楚它是否曾在SQL Server中成为问题，但肯定不再存在。我的DBA看起来已经过时了。

— 乔恩·霍普金斯

似乎没有什么资源可以用来确定编写良好的SQL的共识

那是因为没有共识。举个例子，对于乔恩·霍普金斯列表中至少一半的项目，我会有不同的答案，根据他列表中详细信息的数量，可以肯定地说我们俩都以数据库为生。

也就是说，编码标准仍然是一件好事，并且团队中每个人都理解并同意的标准是更好的事情，因为将更可能遵循该标准。

— 拉里·科尔曼
source

+1。我认为最重要的是，团队之间要保持一致。

— Dean Harding

出于兴趣，您会怎么做？它们在很大程度上是口味问题（布局等）还是有“硬”错误？

— 乔恩·霍普金斯

@Jon：没有硬性错误，只是主观的东西，例如单表名，对触发器的仇恨等等。顺便说一句，“ SELECT *”在“ EXISTS（）”内很好。

— 拉里·科尔曼

公平的例子（我确实在EXISTS上使用它，不要强迫自己喝尿）。

— 乔恩·霍普金斯

除了乔恩·霍普金斯的答案...

独立的内部对象与外部对象
- IX，UQ，TRG，CK等用于约束和索引等
- 小写或CapsCase面向客户，例如uspThing_Add
对于内部对象，如果“非默认”，则使它们明确
- UQ =唯一约束
- UQC =唯一集群约束
- PK =主键
- PKN =非集群主键
- IX =指数
- IXU =唯一索引
- IXC =聚集索引
- IXCU或IXUC =唯一聚集索引
使用架构简化命名和权限。例子：
- 内部处理程序的Helper.xxx
- udfs的HelperFn.xxx
- WebGUI.xxx用于一些面对的代码
- 表的数据和/或历史记录和/或登台

— gbn
source