SQL最佳實踐標識值硬編碼

Question

首先，我知道這是一個相當主觀的問題，但我需要某種形式的正式文件，以幫助我教育我的客戶。

背景 - 與數百個表和SP的大型企業應用程序，都規規矩矩地設計了標準化的表格和使用標識列的外鍵。

我們的客戶有幾個員工寫的用我們的生產DB的複製副本的水晶企業複雜的報表。

我們有表格來存儲我將其分類爲「系統」基本信息的表格，例如公司位置或公司內的部門列表，用戶的標準角色集合，其他對象的狀態（打開/關閉等） ），基本上不經常改變的數據。

問題 - 該報告的設計師和金融分析師他們的寫作裏面用硬編碼標識值的查詢。這樣

SELECT xxx FROM OFFICE WHERE OFFICE_ID = 6 

什麼我大大簡化了這裏，但基本上他們都在用它們的程序內這些硬編碼int類型。

對於SQL開發人員來說，看到這個會很明顯會讓你面對facepalm，因爲它只是一種內建的本能而沒有這樣做。

然而，令人驚訝的是我找不到任何文檔或甚至最佳實踐文章爲什麼這不應該做。

他們會認爲這樣做很好，因爲值永遠不會改變，他們是正確的，在單一系統內，這些值不會改變，但是在多個環境（staging/QA/Dev）中，這些值可以和是完全不同的，它們的報告設計方法不可移植，只能在1個隔離的服務器環境中運行。

是否有任何SQL專家有更深入的信息/文章等，我可以用來幫助教育我的客戶爲什麼他們應該避免這種做法？

Answer 1

對我來說，對你的報告作者來說，最強烈的論據是你的第二個到最後一個句子「......這些價值觀和環境之間可以完全不同」。這幾乎是我對他們的迴應的要點。

當然總是有灰色地帶，任何問題。標識列本質上是magic numbers。他們有益處的是數據庫......

• 小
• 順序
• 快速排序，尋求和加入，創造

...但有缺點完全沒有意義，並且實際上是隨機分配的（將插入按照一種方式排列到該表中，每行得到的身份不同於按照其他方式排序的）。因此，如果你不得不尋找特定的東西，那麼常見的用法還包括「商業/自然/替代」鍵（例如，可能（完全是一個例子）[CategoryName]其中CatgoryName是短的，獨特的和人性化的可讀，而。[CategoryId]是一個身份，但不是想要尋求的東西）

如果你有一個網站，例如下拉菜單，通常自然鍵會被放到下拉菜單的可見部分，而代理/身份密鑰在後端傳遞，對最終用戶不可見。

當人們直接對數據庫寫入查詢時，這會有點棘手。如果他們是數據的擁有者，他們可能知道更大的數據結構，他們可以利用咳嗽「聰明」的方式。如果你知道鍵不會改變，而你知道這些值是什麼，可能有一個情況只是引用那些。但是，如果在查詢不同的服務器時它們會不一樣，那也不是。

當然，另一方面是，如果你不想讓他們使用身份值，你必須給他們一個選擇。如果你的表沒有包含一個業務/自然/備用密鑰，你將不得不添加一個不存在的地方。

另外，這個備用密鑰也不是一個整數（也許你已經在公司範圍內有1,2,3個辦公室的公司標識符），但重要的是，無論你在哪裏運行，它都是確定性的您的查詢。