在SQL Server中只能使用“WITH SCHEMABINDING”？

我有一个数据库，其中有数以百计的名字很尴尬的表格（CG001T，GH066L等），而且我对每个人都有“友好”名字的看法（例如，“CUSTOMERS”是“SELECT * FROM GG120T”） 。 我想在视图中添加“WITH SCHEMABINDING”，这样我就可以拥有一些相关的优点，比如能够对视图进行索引，因为less数视图计算出的列在计算时非常昂贵。

SCHEMABINDING这些观点有缺点吗？ 我发现了一些含糊其辞的文章，但从来没有详细介绍过。 我知道，一旦一个视图是模式化的，你就不能改变任何会影响视图的东西（例如，一个列数据types或sorting规则），而不必先删除视图，那么除了这个之外呢？ 看起来索引视图本身的能力似乎远远超过了更小心地规划模式修改的缺点。

一个都没有。 更安全 我们到处使用它。

除非先放下视图，否则无法更改/删除表格。

哦，有明确的DOWNSIDES使用SCHEMABINDING – 这些来自SCHEMABINDING的事实，尤其是当与COMPUTED列“LOCKS”的关系 ，使一些“微不足道的变化”darn几乎不可能。

  1. 创build一个表。
  2. 创build一个SCHEMABOUND UDF。
  3. 创build一个引用UDF的COMPUTED PERSISTED列。
  4. 在所述列上添加一个INDEX。
  5. 尝试更新UDF。

祝一切顺利！

  1. 因为是SCHEMABOUND，所以UDF不能被删除或改变。
  2. COLUMN不能被删除，因为它在INDEX中使用。
  3. COLUMN不能改变，因为它是COMPUTED。

那么，frak。 真..！？！ 我的一天刚成为PITA。 （现在，像ApexSQL Diff这样的工具可以在提供修改的模式时处理这个问题，但问题在于，我甚至不能修改模式来开始！

我并不反对SCHEMABINDING，在这种情况下（在这种情况下需要一个UDF），但是我反对那里没有办法（我可以find）“暂时禁用”SCHEMABINDING 。

如果这些表来自第三方应用程序（他们臭名昭着地试图隐藏他们的表），如果它试图改变这些表中的任何一个，就会导致升级失败。

您只需在更新/升级之前更改没有模式绑定的视图，然后将其放回。 像其他人提到的一样。 只需要一些规划，纪律等

一个缺点是，如果你使用schemabind视图，它只能引用其他的schemabound视图。

我知道这一点，因为我试图schemabind一个视图，遇到了一个错误消息告诉我，它不能被模式绑定，因为其他视图引用其中一个也不是模式绑定。

这样做的唯一后果是，如果您突然想要更新一个模式绑定的视图来引用一些新的或现有的视图，那么您可能必须对该新的或现有的视图进行模式绑定。 在这种情况下，您将无法更新视图，并且最好希望数据库开发人员知道如何使用具有架构的视图。

另一个缺点是，你需要使用模式限定名称的一切：你会得到像这样的错误消息的负载：

无法架构绑定视图“视图”，因为名称“表”对模式绑定无效。 名称必须采用两部分格式，对象不能自行引用。

另外，为了“closures”模式绑定，你需要改变视图，这需要你重新定义视图的select语句。 我认为唯一不需要重新定义的是任何补助金。 这使得我看起来像是一个固有的不安全的操作。

它有点像添加非空约束的方式迫使你重写列的数据types – 讨厌！

您还必须重新定义依赖于要更改的模式绑定对象的任何其他视图或过程…这意味着您可能必须重新定义（并可能中断）大量的函数和视图级联（例如， ）对一列的非空约束。

我个人认为这并不代表一个解决scheme，更好的是有一个体面的过程，任何数据库更改自动应用，所以它不是一个噩梦来改变数据库。 通过这种方式，您可以将所有视图+函数从头开始删除并重新创build（无论如何都会在创build时进行检查），作为将更改应用到表的过程的一部分。

这对我来说似乎是一个坏处（＃是我的）： 

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.

我有点需要我的左连接。 这个问题是相关的。

当使用tSQLtunit testing框架时，您将遇到问题，并且在使用FakeTable方法时将需要解决方法，这将不允许您伪造链接到具有模式绑定的视图的表。

自SQL Svr 2005以来，所提到的负面因素几乎没有超过这个最佳实践。它避免了可怕的表假脱机。 对我来说，一个主要的负面影响是模式绑定的sprocs，funcs和views，不能包括诸如主数据库这样的“外部”数据库，所以你可以把所有伟大的实时系统的东西扔到垃圾箱里，除非你的生产核心数据库坐落在主人。 对我来说，如果没有系统的东西，我无法处理生活。 当然，并不是所有的处理都需要无缓冲的性能，而快速和慢速的结果可以同时在更高的数据级别层进行组合。

如果您的工具（ssms等）不能很好地处理基础对象的模式更改失败，那么您可能会导致一些真正的混乱。 这就是我现在坐的位置，我意识到这是一个附带案例

Interesting Posts