分隔標識符是否被認爲是Transact-SQL中的「最佳實踐」？

我正在處理一些遺留的SQL，作者分隔了每個列名和數據類型聲明。請參閱以下內容：分隔標識符是否被認爲是Transact-SQL中的「最佳實踐」？

 
CREATE TABLE SomeTable (
    [SomeDate] [datetime] NOT NULL, 
    [SomeInt] [int]  NOT NULL, 
    [SomeString] [nvarchar] NOT NULL 
) ON [PRIMARY] 
GO

在爲SQL Server編寫T-SQL時，這是否被認爲是最佳實踐？由於我現在正在維護這些代碼，我應該繼續這種做法嗎？

來源

2009-12-02 Travis Heseman

這很煩人。 – 2009-12-03 16:33:05

我個人只會寫，如果你使用保留的關鍵字作爲列/表名，你不應該這樣做。就個人而言，我認爲不然，它會使SQL代碼變得不那麼「乾淨」，並且更難以閱讀。

這種風格通常是由SQL工具生成的，因爲它保證不會有任何保留字衝突的問題。

來源

2009-12-02 22:11:46 Marcus

[和] [它] [還] [使] [它] [很多] [更難] [你] [代碼] – 2009-12-02 22:16:50

同意你們兩個......混亂的代碼和bollixes雙擊select-too – gbn 2009-12-03 06:16:32

好吧..我們使用ORM，所以在我們的任何生產代碼中都沒有SQL，我不必擔心混亂。所以我只寫一次藍色月亮的SQL;但是，我們手動編寫數據庫對象創建和修改腳本，並將它們保存在版本控制中，因此我想確保這些腳本能夠達到最佳狀態。 – 2009-12-03 19:09:09

如果表或列的名稱像「SomeInt」一樣是「無害的」，那麼方括號[...]不是必需的 - 如果需要，您可以指定它們，不必這樣做。

在另一方面 - 總是使用這些將確保，即使是「危險」之類'[Message]'和他人的，或者列名列名在他們的場所，如[Product Name]，將永遠是正確的處理。

所以 - 你不必繼續這樣做，但我認爲這是一個很好的做法，如果它已被使用，我建議繼續使用它。

來源

2009-12-02 22:10:31

+1：保持目前的做法是好的 - 它可能不僅僅是你處理這些東西。 – 2009-12-02 22:16:14

我使用過的大多數生成SQL的MS工具都會自動執行此操作（舊的查詢分析器，管理工作室等）。

來源

2009-12-02 22:13:19

[SomeName]是由SQL Server Management Studio自動生成的腳本生成的。就我個人而言，我發現它分散注意力，使名字更難讀。

他們唯一真正的用途是允許標識符中的空格。

即

create table SomeTable 
(
    [some var] int 
)

是有效的（雖然不妥當），同時

create table SomeTable 
(
    some var int 
)

是無效的。

因此，這對於移植/維護傳統項目非常有用。

來源

2009-12-03 16:31:09 Eoin

剛開始使用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

來源

2011-09-16 04:02:22

分隔標識符是否被認爲是Transact-SQL中的「最佳實踐」？

回答

相關問題