正如問題所述,使用NewSequentialID作爲表的默認值與NewID()的缺點是什麼?顯而易見的優勢是它不會像我們的索引一樣碎片化。使用NewSequentialID有什麼缺點嗎?
是否有任何關於永遠最大化序列的問題?
正如問題所述,使用NewSequentialID作爲表的默認值與NewID()的缺點是什麼?顯而易見的優勢是它不會像我們的索引一樣碎片化。使用NewSequentialID有什麼缺點嗎?
是否有任何關於永遠最大化序列的問題?
我不明白一個字段的默認值如何真的成爲一個缺點。
如果您想在插入某些記錄之前控制某些記錄的ID,可以使用NEWID()
而非默認的順序ID(因此您可以在與數據庫交互之前生成記錄及其關聯),以及您將不必在以後查詢它以獲取ID)。雖然兩者並不相互排斥......
由於granadaCoder說,順序編號可以推斷,但IMO的好處是在性能和維護長期如此之大,這將是一個錯誤,不要使用它。
你可以使用UuidCreateSequential來模擬「客戶端」「順序」標識符。正如Thomas所說,guid的好處在於你可以「聯繫」所有關聯運送到數據庫..... aka,您不必等待IDENTITY列返回它們的值以插入子(FK)記錄。但是(如aaron-b所述)存在一些缺點。做出明智的選擇。 – granadaCoder
很好的支持,一,它仍然比,比方說,一個INT一個很寬的關鍵。而且你失去了價值相對隨機且不可預測的魅力之一。您有利於使用GUID(無論是否存在碎片),您有哪些優勢? –
如果您已經意識到int/big_int與GUID參數.....使用NewSequentialID的唯一「缺點」是某人可能會猜到一個GUID。就像,如果你有一個web應用說/EmployeeEdit.aspx?EmployeeKey=123,你的最終用戶可能會「猜到」/EmployeeEdit.aspx?EmployeeKey=124。使用NewSequentialID ... – granadaCoder
可以完成同樣的事情。另一個主要優點是,您可以通過創建日期獲得可靠性排序(如果這對您很重要),即使使用CreateDate列,您也可能無法獲得可靠性排序。 –