Sql-Server
SSMS 中對錶的哪些更改會導致 DROP/CREATE，而 TSQL 總是可以避免這種情況嗎？
我知道在某些情況下，通過 SSMS 的 GUI 對錶進行某些更改（例如，更改列的類型）會導致表被刪除並重新創建。
我的問題是，對於導致這種行為的確切變化是否存在完整的定義？並且是否可以通過執行
ALTER TABLE而不是使用 SSMS GUI 來避免這種行為（如果不能，哪些可以避免，哪些不能）？
我懷疑微軟是否已經在任何地方發布了用於確定 SSMS 如何編寫表更改腳本的邏輯。應該注意的是，SSMS 處理這些問題的方式多年來一直在發展——我發誓在早期版本中，每一個更改都會丟棄並重新創建。現在它肯定會嘗試進行有針對性的調整。
我想不出很多情況下唯一的選擇是 DROP 和 CREATE。在許多情況下，人類或 SSMS 最容易編寫腳本，但大多數情況都可以通過明智地使用
ALTER或刪除和重新創建約束來解決。一個絕對的例外是更改列的順序 - 這確實需要刪除並重新創建表。始終確定您的更改將要做什麼的一種方法是，在表格設計器中，一旦您進行了更改，但在您保存它們之前，請轉到“表格設計器”菜單，然後選擇“生成更改腳本。” 這將準確地告訴您 SSMS 將要執行什麼，並且可以讓您在點擊“保存”之前決定是否要這樣做。
除了您更改數據類型的範例之外，將導致 DROP 和 CREATE 的事情通常涉及對主鍵/集群鍵的更改。移動列會做到這一點，更改基於文本的列的排序規則也是如此。
我不確定你想避免什麼，本身。
ALTER 在程式碼中可能看起來更優雅，但它也可能在後台執行大量工作，冒著截斷或失敗的風險，因此認為刪除和創建更好。
我認為他們的經驗法則是就地數據轉換風險太大，尤其是對於已經包含數據的表，因此創建一個新表更有意義。