分隔标识符是否被视为 Transact-SQL 中的“最佳实践”？答案

【问题标题】：Are delimited identifiers considered a "best-practice" in Transact-SQL?分隔标识符是否被视为 Transact-SQL 中的“最佳实践”？
【发布时间】：2012-01-17 05:34:54
【问题描述】：

我正在处理一些遗留 SQL，作者为每个列名和数据类型声明定界。请参阅以下内容：

创建表 SomeTable ( [SomeDate] [datetime] 非空， [SomeInt] [int] 非空， [SomeString] [nvarchar] 非空 ) 开 [主要] 去

在为 SQL Server 编写 T-SQL 时，这是否被认为是最佳实践？既然我现在在维护这段代码，我是否应该继续练习？

【问题讨论】：

标签： sql-server tsql

【解决方案1】：

我个人只会写，如果您使用保留关键字作为列/表名称，无论如何您都不应该这样做。我个人认为否则，它会使 SQL 代码不那么“干净”并且更难阅读。

这种样式通常是由 SQL 工具生成的，因为它保证不会出现保留字冲突的任何问题。

【讨论】：

[和] [它] [还] [使] [它] [更多] [更难] [到] [类型] [输入] [你的] [代码]
同意你们俩的意见... 代码混乱，而且双击选择也很混乱
嗯.. 我们使用 ORM，所以我们的任何生产代码中都没有 SQL，我不必担心混乱。所以我只写过一次SQL；但是，我们确实手动编写了数据库对象创建和修改脚本并将它们保存在版本控制中，所以我想确保这些都符合要求。
现在，我已经进行了一些挖掘，这些语句似乎是由 SSMS 生成的，但是随着模式的发展，我们手动修改它们并将这些更改检查到 SVN 中。我将继续目前的做法，但手写脚本不会有括号混乱。谢谢

【解决方案2】：

如果表或列的名称是“无害”的，例如“SomeInt”，那么方括号 [...] 不是必需的 - 您可以指定它们，如果需要，不必指定。

另一方面 - 始终使用这些将确保即使是“危险”的列名，如 '[Message]' 和其他人，或其中包含空格的列名，如 [Product Name]，也将始终得到正确处理。

所以 - 你不必继续这样做，但我认为这是一个很好的做法，如果它已经被使用过，我建议继续使用它。

【讨论】：

+1：保持当前的做法很好 - 可能不只是你处理这些东西。

【解决方案3】：

我使用过的大多数生成 SQL 的 MS 工具都会自动执行此操作（旧的 Query Analyzer、Management Studio 等），这没有什么坏处。

【讨论】：

【解决方案4】：

刚开始使用 mssql/t-sql，解决方案可能在需要时使用单引号，因为这涵盖了已弃用的方括号样式和新的双引号样式。如果我错了，请引用我！

一个简单的例子。

1> sp_help sys.tables
2> go
Msg 102, Level 15, State 1, Server
Incorrect syntax near '.'.
1> sp_help 'sys.tables'
2> go
Name                           Owner
------------------------------ ----
tables                         sys
etc

【讨论】：

【解决方案5】：

[SomeName] 是由 SQL Server Management Studio 自动生成的脚本生成的。就我个人而言，我觉得它会分散注意力，并使名称更难以阅读。

它们唯一真正的用途是在标识符中允许空格。

即

create table SomeTable
(
   [some var] int
)

是有效的（虽然不建议），而

create table SomeTable
(
   some var int
)

无效。

因此它对于移植/维护遗留项目很有用。

【讨论】：