Webforms上的主鍵（最初加載還是保存）？

Question

無論數據庫的體系結構如何，這只是一個普遍的問題。 我正在維護一個ASP.NET Web應用程序。 結構是這樣的，

說“添加新員工”網絡表單

• 主鍵（或要保存的記錄ID）最初在表單加載事件中加載並顯示為標簽
  • 因此，當表單加載時，要保存的記錄ID會顯示給用戶

正面：

• 最終用戶已經知道表單的ID /序列號是什么（甚至在保存表單之前）
• 因此，在保存表單時，當他被定向到Gridview屏幕（包含所有條目）時，他可以輕松地搜索記錄（盡管最近的記錄始終位於頂部）

劣勢：

• 如果他不保存表單，比如說他只是在加載數據輸入表單后取消，那么最初獲取的id /鍵就被浪費了（在我的情況下，這是從數據庫加載表單時獲取的序列字段）

你們在這些情況下會做什么？ 您將為“ Web應用程序”推薦哪種方法？ 以及如何以不同的方式方便用戶？ 是否建議使用我們當前的方法（對我來說，這浪費了數據庫中的ID /序列）

Answer 1

我總是建議不要在創建記錄之前不提供正在創建的記錄的標識字段值。 如您提到的，“首先創建臨時占位符記錄以提前獲取標識字段值”方法可能會導致浪費ID，除非您有適當的過程來回收它們。

當用戶按下保存時，您總是可以彈出一個消息框，告訴他們新創建的記錄的標識字段值。

Answer 2

在這種情況下，您可以使用由應用程序本身創建的GUID。 然后，數據庫將僅將PK設置為唯一標識符（GUID），並且它不能為null。 在這種情況下，您不會浪費任何唯一鍵，因為每次獲取新GUID的調用都應定義為生成（數學上）唯一的標識符。 值得注意的是，如果使用此方法，則最好確保未將PK設置為集群。 插入后產生的索引重組可能很快導致應用程序性能下降。

Answer 3

例如：我不會在乎浪費的id值。 當您有可能用盡int32值的危險時（最后一次發生這種情況是什么？），請使用int64。 用戶體驗比浪費一些id值重要得多。

話雖如此，我不希望主鍵是用戶想要鍵入的任何內容。如果您擁有用戶需要輸入的主鍵，那么可能（或將要求輸入）更多不僅僅是一個int32 / 64值，並且在其組成和/或格式中帶有（將帶有）含義。 主鍵不應具有該功能。 （出於各種原因，谷歌搜索了毫無意義的主鍵或其他類似術語）。

如果您需要一個有意義的鍵，則使其成為與主鍵完全無關的二級索引。 如果其中一部分仍然是從數據庫中某個計數器值獲取的序列號。 確定在功能上是否在序列中出現缺口是一個問題。 （稅務人員通常不希望發票號有空白）。 如果在功能上沒有問題，那么一定不要從技術上開始擔心它。 如果從功能上來說是個問題，那么是的，您別無選擇，只能等待保存才能顯示給用戶。 但是，請不要在彈出窗口中這樣做。 他們非常令人討厭，因為他們不得不被解雇。 只需在保存新員工之后在屏幕上顯示一條提示性消​​息，向用戶發送該消息。 就像gmail會告訴您有關您在郵件列表上方執行的操作一樣。