SQL Server:向 C 級主管解釋在整個數據庫的許多表中使用 VARCHAR(50) 的主鍵的影響?
假設一家全球中型公司正在考慮一種文件控制管理解決方案,該解決方案由 SQL Server 數據庫支持,並允許開發人員使用表單創建工具創建文件表單類型。使用該工具創建的每種表單類型在數據庫中由一個主鍵為 datatype 的表表示
VARCHAR(50)
。與使用更傳統的設計方法(例如,this
VARCHAR(50)
)的系統相比,使用主鍵的要求對系統性能有什麼影響?假設答案的核心受眾大多是非技術人員,即 C 級主管對解決方案做出是否通過的決定。筆記:
文件控制管理系統需要為全球中型公司執行典型的文件控制管理系統任務多年(至少二十年)。
這是一個固定的解決方案,不能更改主鍵數據類型。
數據類型映射到公司的
VARCHAR(50)
產品序列號。序列號格式是字母數字,可以包含破折號。該系統基於 Web 並使用 SQL Server 2014 和 .NET Framework (C#) 技術堆棧。
在創建此問題之前研究的問題,所有這些問題都與技術堆棧不一致和/或在雜草中也為非技術受眾提供了答案:
文件控制管理系統需要執行典型的文件控制管理系統任務……多年(至少二十年)。
對 SQL Server 2014 Service Pack 3 的擴展支持將於 2024 年 7 月 9 日結束。那是5年後。因此,我認為您的第一步應該是查看供應商是否/何時打算在更現代的 SQL Server 版本上獲得認證。如果您遵守要求軟體接收供應商支持和安全更新的合規性規則,這一點更為重要。
至於與執行利益相關者分享的其他內容,很難做出籠統的陳述,因為您肯定不會比較除主鍵數據類型外具有完全相同架構的系統。
如果您將此產品與使用代理(整數)鍵的類似產品進行比較,假設 varchar(50) 主鍵也是聚集索引(SQL Server 的預設值),您可能會提出以下問題:
您可能需要為數據庫增加的磁碟空間付費
由於上述原因,您還將在磁碟空間上花費更多用於備份
您可能需要為更多 RAM 付費
- 由於這些表和索引在磁碟上更大,它們在 RAM 中也會更大
某些報告和螢幕的載入速度可能較慢
- 索引掃描和查找將不得不消耗更多的頁面,並且會比它們等效的整數鍵控表掃描花費更長的時間
某些報告和螢幕的載入速度可能更快
- 由於此序列號的文本將儲存在將其作為外鍵引用的任何表中,因此您有時可以避免連接
注意上面所有的對沖詞,比如“可能”和“可能”——就像我說的,我認為你不能就這種情況做出很多有用的一般性陳述。