添加表格的唯一鍵/索引及其對現有記錄的影響

我有一張桌子，迄今爲止沒有唯一的鍵就很好。這個表格工作正常，但插入/更新/刪除過程的代碼變得有點不可讀，因爲識別表中正確條目的條件變得越來越長，所以我開始考慮添加一個帶有唯一ID的新列。添加表格的唯一鍵/索引及其對現有記錄的影響

已經回答了關於在SO上爲表添加唯一標識的問題，但我想知道它是否會對正確存在的記錄產生任何負面影響。表格本身並不大，從來沒有超過幾千個條目，但它經常被使用和更新，並且停止使用它不是一件容易的事情。那麼，有什麼我應該知道的，可能會弄亂數據，或者我可以愉快地添加一個具有獨特身份的專欄，一切都會正常工作？當前存在的存儲過程是否存在問題，尤其是那些更改記錄的問題？說實話，我想不出什麼，但我寧願確定，因爲我遠沒有在SQL和數據庫方面的經驗。

將索引添加到已經存在的表格中 - 我想會涉及到一些轉換，那麼是否會對記錄產生負面影響？

如果您需要我提到的過程的示例，只需考慮簡單的插入/刪除/更新語句，並在不必要的地方使用where子句。不與其他表格進行連接，不會在單個過程中進行多次事務。

來源

2013-12-11 S_F

如果您還沒有*某種形式的數據密鑰，那麼添加新數據對於缺乏數據質量根本無濟於事 - 如果您目前沒有強制執行密鑰，則沒有任何措施可以停止您有兩個（或更多）行在每列中包含完全相同的值。添加一個新列來唯一標識這些行並不能解決您在數據中仍然存在重複的事實。 –

@Damien_The_Unbeliever在質量方面你是對的，但我從SP的可讀性角度考慮這種變化，以及使用數據庫管理應用程序側的數據。目前如果我想要例如更新記錄，我需要傳遞不必要的大量數據作爲參數才能找到它。 –

當前數據不會受到添加列或更改索引的影響。

但代碼可能會受到影響。

SELECT *現在將返回更多列。
列順序可能會根據添加列的位置而變化。
有人可能INSERT沒有列列表。現在會失敗。
性能可能會變得稍差。如果你的應用依賴於非常嚴格的性能標準，那可能是一個問題。我認爲這不太可能。

我確定還有其他人，但這些是我現在可以想到的。

來源

2013-12-11 10:36:01 usr

爲什麼添加一個唯一的密鑰可能是性能方面的問題？我認爲在添加ID後，如果大部分long where子句從插入/更新等消失，它實際上可能會更快。 –

如果修改查詢以利用它們，這很可能有所幫助，是的。你可能會意識到一些收益。我的評論是針對你只是添加列而不改變其他內容的情況。我以爲你擔心現有代碼在變化下的行爲。 – usr

添加表格的唯一鍵/索引及其對現有記錄的影響

回答

相關問題