SQL Server - 您的團隊有哪些編碼/開發規則？

上週我問了一個類似的問題，沒有得到很好的答覆，所以也許我沒有以正確的方式提出問題。SQL Server - 您的團隊有哪些編碼/開發規則？

我想知道您的團隊在編寫T-SQL代碼和數據庫模式方面有哪些流程/政策/規則。這裏有幾個例子：

1) All foreign key columns should be indexed 
2) All primary key columns should be integer Identity 
3) All stored procedures/user defined functions need comments 
4) No underscores in T-SQL variable names

這些是我很好奇的東西。

謝謝！

來源

2010-04-26 Randy Minder

這真的是社區wiki的東西。 – 2010-04-26 11:21:26

他在石頭上寫規則，後來希望得到一大瓶白葡萄酒！除了格式化/樣式/命名/源代碼過程之外，只是堅持準則而不是絕對規則。您可能需要使用不同的PK（某天的非標識）或不需要FK上的索引等。 – 2010-04-26 11:37:08

不是真的。我們在某些較大的桌面FK上沒有索引，因爲我們從不刪除或更新父值，或選擇性較差。大多數情況下，但明白了原因。也就是說，我會使用3位代碼本身來存儲ISO貨幣代碼（如CHF或GBP）的表格。而且你仍然需要對自然鍵的唯一約束

來源

2011-01-22 12:46:15 gbn

我不同意索引的所有外鍵。如果您擁有一個只有3個選項的主表的外鍵，那麼在一個包含數百萬行的表中，您會產生無謂的索引。從關鍵到數據的反向查找是不太可能的。

來源

2010-04-26 11:23:59 cjk

似乎＃1，＃2和＃3都是相當差的規則。索引外鍵並不總是必要的。當一個好的自然鍵存在時，創建一個代理鍵是沒有意義的。評論不會編譯，因此它們很容易與代碼不同步，並可能欺騙讀者。只有在絕對必要時才能使用它們。評論完成一條堅強而快速的規則比浪費時間更糟糕。

項目＃4是相當不錯的。團隊我曾一直更關心的事情，去實施的質量工作（例如良好的錯誤在所有存儲過程的處理和存儲過程做的只有一件事）

來源

2010-04-26 11:25:16

在處理數據庫的30年中，我很少遇到真正的自然鍵。由於性能原因，代理通常比自然密鑰更好。如果您擁有真正的自然鍵，則與子表相關的代理鍵和自然鍵上的唯一索引通常是性能最佳的選項。 – HLGEM 2010-04-26 15:26:36

SQL Server - 您的團隊有哪些編碼/開發規則？

回答

相關問題