2 回答

TA貢獻1874條經(jīng)驗 獲得超12個贊
一般來說,自動遞增(或identity
或serial
)主鍵是可行的方法。您通常不希望應用程序擔心諸如值是否已被使用之類的事情。
如果您的應用程序是多線程的(即同時有多個用戶),那么數(shù)據(jù)庫將處理任何沖突。那是相當方便的。
我很喜歡數(shù)據(jù)庫創(chuàng)建的代理鍵。在按主鍵對行進行聚類(排序)的數(shù)據(jù)庫中,使用自動遞增的值會更有效。數(shù)據(jù)庫可以解決這個問題。
在某些情況下,您需要自然鍵。當然,這也是允許的。但是,如果您要為表發(fā)明主鍵,請讓數(shù)據(jù)庫來完成這項工作。

TA貢獻1829條經(jīng)驗 獲得超6個贊
在為 CRUD 操作定義數(shù)據(jù)庫支持結(jié)構(gòu)時,您需要問自己:
我的主鍵高度可預測重要嗎?
我的意思是,如果我將用戶啟動到諸如“whatever.com/something/edit/1”之類的屏幕
除了明顯的安全性之外,用戶可以操縱 url 并將 2 或 3 或 4 注入路徑中是否有助于或損害業(yè)務流程?
如果沒關(guān)系,那么絕對將其設置為數(shù)據(jù)庫端的自動增量 int 并將該區(qū)域的責任轉(zhuǎn)移給數(shù)據(jù)庫來處理。您現(xiàn)在不必再高度關(guān)注處理密鑰生成。
如果確實重要,則將主鍵設置為唯一標識符。在代碼中添加新記錄集時,您將生成一個新的 GUID 并將其設置為主鍵 (Guid.NewGuid())。這將防止用戶以不受控制的方式遍歷您的數(shù)據(jù),因為隨機猜測 GUID 會給他們帶來問題。EX:新路徑:“whatever.com/something/edit/0f8fad5b-d9cb-469f-a165-70867728950e”
并不是說不可能偶然發(fā)現(xiàn)一些東西,但使用您的應用程序的普通人不會那么傾向于去探索 url 操作,因為他們會浪費 99.99% 的時間在無效的帖子上嘗試猜測已注冊的有效 GUID在你的數(shù)據(jù)庫中。
作為補充評論,如果您決定將主鍵保留為 int 并且不使用自動增量,那么您只是在為自己做大量不必要的工作,而我個人從未見過邏輯的任何真正投資回報您應該檢查占位符是否已被使用。那并考慮追蹤歷史嗎?如果您決定從表中刪除記錄然后重新使用它們,那么您將陷入痛苦的世界。除了你正在做的事情之外,這是你必須處理的另一組問題。
- 2 回答
- 0 關(guān)注
- 144 瀏覽
添加回答
舉報