Недостатки "С SCHEMABINDING" в SQL Server? - PullRequest
58 голосов
/ 02 ноября 2009

У меня есть база данных с сотнями неловко названных таблиц (CG001T, GH066L и т. Д.), И у меня есть представления о каждой из них с ее "дружественным" именем (представление "CUSTOMERS" - "SELECT * FROM GG120T", например). Я хочу добавить «WITH SCHEMABINDING» к моим представлениям, чтобы иметь некоторые преимущества, связанные с ним, например, возможность индексировать представление, поскольку несколько видов имеют вычисляемые столбцы, которые дорого вычислять на лету.

Есть ли недостатки в планировании этих представлений? Я обнаружил некоторые статьи, которые смутно ссылаются на недостатки, но никогда не вдавались в них подробно. Я знаю, что, когда представление привязано к схеме, вы не можете изменить что-либо, что могло бы повлиять на представление (например, тип данных столбца или сопоставление), без предварительного удаления представления, так что это одно, но кроме этого? Кажется, что возможность индексировать само представление намного перевесило бы недостатки более тщательного планирования изменений схемы.

Ответы [ 10 ]

44 голосов
/ 02 ноября 2009

Вы не сможете изменить / удалить таблицу, если только вы сначала не удалите представление.

31 голосов
/ 02 июля 2013

О, есть ОПРЕДЕЛЕННО СУЩЕСТВУЮЩИЕ для использования SCHEMABINDING - они происходят из факта SCHEMABINDING, особенно в сочетании со столбцами COMPUTED «ЗАМКИ» ОТНОШЕНИЯ и вносят некоторые «тривиальные изменения» штопать почти невозможно.

  1. Создать таблицу.
  2. Создайте схему UDF.
  3. Создайте столбец COMPUTED PERSISTED, который ссылается на UDF.
  4. Добавить индекс над указанным столбцом.
  5. Попробуйте обновить UDF.

Удачи с этим!

  1. UDF нельзя удалить или изменить, потому что это SCHEMABOUND.
  2. КОЛОННА не может быть отброшена, потому что она используется в INDEX.
  3. КОЛОННА не может быть изменена, потому что она ВЫЧИСЛЕНА.

Ну, фрак. В самом деле..!?! Мой день просто стал пита. (Теперь такие инструменты, как ApexSQL Diff, могут обрабатывать это , если предоставляется модифицированная схема , но проблема здесь в том, что я даже не могу изменить схему для начала!)

Я не против SCHEMABINDING, ум (и в этом случае это необходимо для UDF), но Я против того, что у меня нет способа (который я могу найти) "временно отключить" SCHEMABINDING .

27 голосов
/ 02 ноября 2009

Нет вообще. Это безопаснее. мы используем его везде.

4 голосов
/ 06 марта 2013

Недостатком является то, что если вы привязываете схему к представлению, оно может ссылаться только на другие привязанные к схеме представления.

Я знаю это, потому что я пытался связать схему представлением и получил сообщение об ошибке, сообщающее, что оно не может быть привязано к схеме, потому что одно из других представлений, на которые он ссылается, также не привязано к схеме.

Единственным следствием этого является то, что если вы вдруг захотите обновить привязанное к схеме представление, чтобы ссылаться на какое-то новое или существующее представление, вам, возможно, придется привязать к схеме это новое или существующее представление. В этом случае вы не сможете обновить представление, и вам лучше надеяться, что разработчики вашей базы данных знают, как работать с представлениями со схемой.

4 голосов
/ 03 ноября 2009

Если эти таблицы взяты из стороннего приложения (они печально известны тем, что пытаются скрыть свои таблицы), вы вызываете неудачное обновление, если оно пытается изменить любую из этих таблиц.

Вы просто должны изменить представления без привязки схемы перед обновлением / обновлением и затем вернуть их обратно. Как и другие уже упоминали. Просто нужно немного планирования, дисциплины и т. Д.

2 голосов
/ 09 апреля 2014

Другим недостатком является то, что вам нужно использовать имена, соответствующие схеме, для всего: вы получите множество сообщений об ошибках, таких как:

Невозможно представление привязки схемы «представление», поскольку имя «таблица» недопустимо для привязка схемы. Имена должны быть в формате из двух частей, и объект не может сама ссылка.

Также, чтобы «отключить» привязку схемы, вы изменяете представление, которое требует от вас переопределения оператора выбора представления. Я думаю, единственное, что вам не нужно переопределять, это любые гранты. Это сильно отталкивает меня, поскольку перезапись представления кажется небезопасной операцией.

Это немного похоже на то, как добавление ненулевых ограничений заставляет вас перезаписывать тип данных столбца - неприятно!

Вы также должны будете переопределить любые другие представления или процедуры, которые зависят от привязанного к схеме объекта, который вы хотите изменить ... это означает, что вам, возможно, придется переопределить (и, возможно, нарушить) большой каскад функций и представлений только для того, чтобы добавить (например) ненулевое ограничение к одному столбцу.

Лично я думаю, что на самом деле это не представляет собой решение, и лучше иметь достойный процесс, при котором любые изменения в базе данных применяются автоматически, поэтому изменение базы данных не является кошмаром. Таким образом, вы можете удалить все свои представления и функции и заново создать их (они все равно проверяются при создании) как часть процесса, когда вы применяете изменения к таблицам.

1 голос
/ 19 февраля 2016

Упомянутые негативы едва ли перевешивают эту лучшую практику, начиная с SQL Svr 2005. Это позволяет избежать страшной буферизации таблиц. Основным минусом для меня является то, что связанные со схемой sprocs, funcs, views не могут включать в себя «чужие» базы данных, такие как master db, так что вы можете выбросить все великолепные системные компоненты реального времени в корзину, если, например, ваше производственное ядро База данных находится внутри мастера. Для меня я не могу иметь дело с жизнью без системного материала. Конечно, не вся обработка требует производительности без буферизации, и быстрые и медленные результаты можно комбинировать одновременно на более высоких уровнях классов данных.

1 голос
/ 17 февраля 2016

При использовании tSQLt Unit Test Framework вы столкнетесь с проблемами, и вам понадобятся обходные пути при использовании метода FakeTable, который не позволит вам подделать таблицу, связанную с представлением с привязкой к схеме.

1 голос
/ 04 марта 2015

мне это кажется недостатком (# мои):

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.

Мне нужны мои левые соединения. Этот ТАК вопрос актуален.

0 голосов
/ 10 ноября 2016

Если ваш инструмент (ssms и т. Д.) Не обрабатывает сбои изменения схемы на базовом объекте хорошо / изящно, вы можете вызвать настоящий хаос. Вот с чем я сейчас сижу, и я понимаю, что это крайний случай

...