T-SQL编码标准有没有好的资源？
答案 0 :(得分：4)
查看这个优秀的资源：
SSW Rules to Better SQL Server Databases
这也很好，虽然自2001年文章发表以来，一些建议可能已经改变了）：
SQL Server TSQL Coding Conventions, Best Practices, and Programming Guidelines
答案 1 :(得分：2)
我是ASP.NET应用程序的开发人员，我的经理要求我将我的SQL语句提交给DBA进行审核。我所做的是将应用程序中使用的所有SQL合并到一个模块文件中。 （带有只读字符串的VB .NET模块）
仅举几个命令即可。
E.g。使用“SELECT username FROM user WHERE userid = @userid”而不是 Dim sql as String =“SELECT username FROM user WHERE userid = {0}” sql = String.Format（sql，userid）
不应使用“SELECT *”。必须明确命名列。
应尽可能使用JOINS代替NESTED QUERIES。
减少使用VIEWS，因为这会影响性能。 （这是有争议的）我的经理走到极端，禁止使用观点。我们将开发一些性能和可伸缩性比代码的可读性更重要的东西。
答案 2 :(得分：1)
对于SQL编码标准，最好的办法是搜索其他人编写的内容。有几种资源包含各种人发布的标准。你不太可能找到一个完全适合你的组织。另外，有些人有恕我直言的标准。您最好的选择是阅读您找到的文档，并提取有意义且适合您组织的概念和规则。有些标准可能有点过分，比如如何缩进代码。这取决于您希望标准的严格程度。以下是一些例子：
http://www.nyx.net/~bwunder/dbChangeControl/standard.htm
http://www.SQLserverPortal.com
你必须环顾两个和第三个链接，因为我没有准确的URL。另请查看上面Mitch Wheat发布的链接。这些只是一些例子，但你可以通过搜索找到更多。
答案 3 :(得分：0)
我在多个组织中为SQL Server做出了贡献或实现了编码实践。您可以花几天时间研究其他人所做的事情但是您可以使用它们，但我发现每个环境都是完全独特的。
在高层......我建议尽可能地将功能与形式分开。我的意思是什么？有一些最佳实践可以针对您的特定环境和应用程序进行测试和记录，例如何时在大型查询上使用临时表，无锁，动态sql使用，查询提示，配置。这些可能完全取决于硬件和使用。然后还有其他更基于意见的标准：命名约定，模式的使用，过程，视图，函数，版本控制等。后一组可以变得相当政治 - 真的是政治性的。从小处着手也是一个好主意 - 一次执行一点。
在外部供应商处，我发现在影响性能之前影响是不切实际的（例如：导致大量表扫描的显式查询提示）。然后提供数据并让它们进行修补是最有效的。如果有某种服务合同，我看不出你如何执行实践。请注意，他们可能正在为多个版本和/或平台编写代码，并希望代码尽可能灵活。
答案 4 :(得分：-2)
我建议从codeplex.com下载并安装示例数据库AdventureWorks
http://www.codeplex.com/MSFTDBProdSamples
它是由Microsoft员工创建的，具有非常好的设计，可以作为一个例子（最佳实践）。
我还建议您阅读本书：
