我在它（CG001T，GH066L等）有數百笨拙命名錶的數據庫，我對每一個與它的「友好」名稱（視圖「顧客」的意見是「SELECT * FROM GG120T」，爲例）。我想在視圖中添加「WITH SCHEMABINDING」，這樣我就可以擁有一些與它相關的優點，比如能夠爲視圖編制索引，因爲少數幾個視圖計算出了即時計算昂貴的列。在SQL Server中有「WITH SCHEMABINDING」的缺點？
SCHEMABINDING這些視圖有缺點嗎？我發現了一些隱約暗示缺點的文章，但從來沒有詳細討論過。我知道，一旦視圖是模式綁定的，在不首先放棄視圖的情況下，不能改變會影響視圖的任何內容（例如，列數據類型或排序規則），所以這只是一個，但除此之外呢？似乎索引視圖本身的能力遠遠超過了更小心地規劃架構修改的缺點。
如果這些表來自第三方應用程序（它們因嘗試隱藏表格而臭名昭着），那麼如果它試圖更改這些表中的任何一個，則會導致升級失敗。
您只需在更新/升級之前更改沒有模式綁定的視圖，然後將其放回。像其他人所說的那樣。只需要一些規劃，紀律等。
我想這是事實，並且比在DDL期間放棄視圖的侵入性要小得多。我最近不得不在一些列上更改排序規則，只是在執行ALTER/Change排序規則/ ALTER時比放下視圖和中斷應用程序要容易得多。 – SqlRyan 2009-11-03 16:30:55
不幸的是，簡單地通過ALTER語句刪除SCHEMABINDING不適用於索引視圖，因此在這些情況下，我相信唯一的解決方案仍然是刪除並重新創建視圖。 – jpierson 2010-08-19 15:51:35
我剛剛在索引視圖上測試了ALTER VIEW，看看會發生什麼。我期待着看到某種類型的錯誤（一種好的方式是典型的SQL Server），但它只是刪除了我的索引。所以要小心在視圖上使用ALTER來改變它是否是模式綁定或不知道它是否有索引。 – jpierson 2010-08-19 16:01:14
一個缺點是，如果您對一個視圖進行schemabind綁定，那麼它只能引用其他的綁定了視圖的視圖。
我知道這是因爲我試圖schemabind視圖，並會見了一個錯誤信息，告訴我它無法架構綁定，因爲它引用其他視圖一個是不是也架構綁定。
這樣做的唯一的後果是，如果你突然要更新架構綁定視圖引用一些新的或現有的視圖，你可能需要schemabind新的或現有的視圖中。在這種情況下，您將無法更新視圖，並且您最好希望數據庫開發人員知道如何使用架構綁定視圖。
哦，還有DEFINITELY缺點使用SCHEMABINDING - 這些來自事實SCHEMABINDING，尤其是當與計算列再加「鎖定」關係，使幾乎不可能該死的一些「瑣碎的變化」。
祝你好運的！
那麼，frak。真..！？！我的一天剛成爲PITA。 （現在，像ApexSQL DIFF工具時，用修改過的模式提供可以處理這個，但問題是在這裏，我甚至不能修改，開始與該模式！）
我不反對SCHEMABINDING，頭腦（在這種情況下它需要一個UDF），但是我反對那裏沒有辦法（我可以找到）「暫時禁用」SCHEMABINDING。
你的意思是你可以創建一些循環的SCHEMABOUND引用？有沒有什麼辦法擺脫這種情況，而不是在沒有SCHEMABINDING OPTION的情況下刪除/重新創建數據庫？ （在你的情況下刪除索引可以解除阻止嗎？） – Guillaume86 2014-10-23 13:27:43
「1. UDF不能被刪除或更改，因爲它是SCHEMABOUND。」不，這與模式綁定所做的相反。 「3. COLUMN不能改變，因爲它是COMPUTED。」咦？你什麼意思？ – MarredCheese 2018-02-09 20:30:55
另一個缺點是，你需要使用的模式限定名的一切：你會得到錯誤信息的負載是這樣的：
無法架構綁定視圖「視圖」，因爲名稱「表」是無效的爲 架構綁定。名稱必須採用兩部分格式，並且對象不能引用其自身。
另外，爲了「關閉」模式綁定，你需要改變視圖，這需要你重新定義視圖的select語句。我認爲唯一不需要重新定義的是任何補助。由於覆蓋視圖看起來像是一種固有的不安全操作，這使我感到很失望。
它有點像添加非空約束的方式迫使你覆蓋列的數據類型 - 討厭！
您還必須重新定義依賴於要更改的模式綁定對象的任何其他視圖或過程......這意味着您可能必須重新定義（並可能打破）大量級聯函數和視圖將（例如）非空約束添加到一列。
就我個人而言，我認爲這並不代表一個解決方案，它更好地擁有一個體面的過程，因此任何數據庫更改都會自動應用，因此更改數據庫並不是一場噩夢。通過這種方式，您可以將所有視圖+函數從頭開始刪除並重新創建（無論如何都會對創建進行檢查），作爲將更改應用到表的過程的一部分。
這似乎是一個缺點，我（＃'的手筆）：
Cannot create index on view "###.dbo.###" because it uses a LEFT, RIGHT, or FULL OUTER join, and no OUTER joins are allowed in indexed views. Consider using an INNER join instead.
我還挺需要我的左連接。 This SO question是相關的。
當使用tSQLt單元測試框架時，您會遇到問題，並且在使用FakeTable方法時將需要解決方法，這將不允許您僞造鏈接到具有模式綁定的視圖的表。
自SQL Svr 2005以來，所提到的負面因素幾乎不會超過這個最佳實踐。它避免了可怕的表假脫機。對我來說，一個主要的負面影響是模式綁定的sprocs，funcs，views不能包含諸如主數據庫之類的「外部」數據庫，因此您可以將所有優秀的實時系統內容放入垃圾箱中，除非您的生產核心數據庫位於主站內。對我來說，沒有系統的東西我就無法處理生活。當然，並非所有的處理都需要無滑動的性能，而快速和慢速的結果可以在更高的數據級別層同時進行組合。
如果您的工具（ssms等）不能很好地處理基礎對象上的模式更改失敗，那麼您可能會導致一些真正的混亂。這就是我現在正在坐的，而且我確實意識到這是一個附帶案例
您不必刪除視圖，但是您必須在刪除了模式綁定的情況下更改視圖。 – JeffO 2009-11-03 03:28:05