Недостатки использования схемы в SQL Server?

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

Есть ли недостатки у СХЕМЫ РАЗРАБОТКИ этих представлений? Я нашел несколько статей, в которых нечетко упоминаются недостатки, но я никогда не вдавался в подробности. Я знаю, что когда представление построено по схеме, вы не можете изменить что-либо, что могло бы повлиять на представление (например, тип данных столбца или сопоставление) без предварительного удаления представления, так что это одно, но кроме этого? Кажется, что возможность индексировать само представление намного перевешивает обратную сторону более тщательного планирования модификаций схемы.


sql sql-server query-optimization schemabinding
person SqlRyan    schedule 02.11.2009    source источник
comment
Вам не нужно отбрасывать представление, но вам нужно изменить представление, удалив привязку схемы.   -  person JeffO    schedule 03.11.2009

Ответы (10)


arrow_upward
33
arrow_downward

Вовсе нет. Так безопаснее. мы используем его везде.

person gbn    schedule 02.11.2009
comment
Если нет недостатков и это безопаснее (каково было мое первое впечатление), то почему бы людям не использовать его? Похоже, что защита ваших представлений от случайной поломки будет приоритетом, или как будто должно быть наоборот - WITH по умолчанию, и вы должны объявить свои представления БЕЗ, если вы хотите такого поведения. - person SqlRyan; 02.11.2009
comment
лень, слишком много дисциплины (например, квалифицированные колонки и т. д.) - person gbn; 02.11.2009
comment
Есть ли способ сделать это параметром по умолчанию или это всегда нужно делать осознанно? - person SqlRyan; 02.11.2009
comment
Я также хотел бы знать, почему отрицательные голоса - поскольку я задал этот вопрос три года назад, и вы ответили, я обычно использую этот модификатор везде и не видел никаких побочных эффектов, и приятно знать, что лежащие в основе таблицы не может быть изменен из-под просмотров. - person SqlRyan; 18.12.2012
comment
@SqlRyan: спасибо за отзыв. Ответ от DanS полезен, но я не вижу в этом проблемы. Потому что он останавливает такие вещи: stackoverflow.com/a/323103/27535 - person gbn; 19.12.2012
comment
У меня это случилось около месяца назад - я изменил базовую таблицу, и представление было возвращено с полностью искаженными результатами. Оказалось, что представление использовало SELECT * FROM, и мне пришлось обновить представление, прежде чем он понял, что основная схема изменилась :) - person SqlRyan; 20.12.2012
comment
Что происходит, когда вы используете что-то, что автоматизирует создание таблиц базы данных, например Microsoft MVC в Visual Studio, и вам нужно воссоздать таблицы? Не получилось бы, если бы представление было привязано к нему? Кроме того, я даже не могу создавать индексы для представлений в SQL Server со столбцами, которые выполняют доступ к данным, или представления с подзапросами, и в этот момент сообщение об ошибке забавно предлагает рассмотреть возможность изменения представления, чтобы использовать только соединения вместо подзапросов. В качестве альтернативы можно не индексировать это представление. Хорошо, тогда! - person Triynko; 06.03.2013
comment
@Triynko: для этого есть веские причины. Любые изменения в базовых таблицах, требующие воздействия на все индексированное представление, запрещены. SUM легко вычислить, например, только для измененных строк. Кроме того, я не верю, что создание слепого стола - хорошая идея: продвинутый SQL и подобная разработка несовместимы. - person gbn; 06.03.2013

arrow_upward
48
arrow_downward

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

person Dan S    schedule 02.11.2009
comment
На мой взгляд, это большая проблема, особенно если вы хотите изменить структуру базы данных без удобных исходных операторов DDL. В этих случаях вы должны попытаться сгенерировать полные операторы DDL для представлений / функций с помощью SCHEMABINDING, отбросить их, а затем воссоздать их. Достаточно большая задача - просто изменить размер колонки. - person jpierson; 19.08.2010
comment
Вам не нужно отбрасывать представление как таковое, просто ИЗМЕНИТЕ его, чтобы оно не было привязано к схеме, а затем ИЗМЕНИТЕ его обратно. - person Paul; 28.11.2011

arrow_upward
33
arrow_downward

О, есть ОПРЕДЕЛЕННО СНИЖАЕТ использование SCHEMABINDING - они исходят из самого SCHEMABINDING, особенно в сочетании с ВЫЧИСЛЕННЫМИ столбцами "БЛОКИРУЕТ" ВЗАИМООТНОШЕНИЯ и вносит некоторые "тривиальные изменения", черт возьми почти невозможно.

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

Удачи с этим!

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

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

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

person user2246674    schedule 02.07.2013
comment
Вы имеете в виду, что можно создать несколько циклических ссылок SCHEMABOUND? Есть ли способ выйти из этого, кроме как просто удалить / воссоздать базу данных без ОПЦИИ SCHEMABINDING? (сброс индекса в вашем случае может разблокировать вас?) - person Guillaume86; 23.10.2014
comment
1. UDF не может быть удален или изменен, потому что он РАСПИСАН. Нет, это противоположно тому, что делает привязка схемы. 3. КОЛОНКА не может быть изменена, потому что она ВЫЧИСЛЕНА. Хм? Что ты имеешь в виду? - person MarredCheese; 09.02.2018
comment
1. UDF не может быть удален или изменен, потому что он РАСПИСАН. Это не имеет ничего общего с SCHEMABINDING, а скорее с тем, как вы используете UDF в вычисляемом столбце. 3. КОЛОНКА не может быть изменена, потому что она ВЫЧИСЛЕНА. Эмм, да? Это не имеет ничего общего с SCHEMABINDING, но со способом работы (MS) SQL. - person Tom Lint; 11.12.2019
comment
В этом ответе говорится, что если я создам длинную цепочку объектов схемы, каждый из которых зависит от предыдущего объекта, мне, возможно, придется временно изменить или удалить (а не просто отключить) некоторые из них в порядке, обратном их добавлению, так что я может изменить схему в нижней части башни. Это то же самое, что OP имел в виду, говоря, конечно, о более тщательном планировании модификаций [своей] схемы. Но пример UDF по-прежнему поучителен. - person Jirka Hanika; 02.02.2021

arrow_upward
5
arrow_downward

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

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

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

person Triynko    schedule 06.03.2013

arrow_upward
4
arrow_downward

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

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

person JeffO    schedule 03.11.2009
comment
Я полагаю, что это правда, и это гораздо менее агрессивно, чем отключение представления на время вашего DDL. Недавно мне пришлось изменить сопоставление в некоторых столбцах, и просто выполнить ALTER / Изменить сопоставление / ALTER было бы намного проще, чем отбросить представление и сломать приложение, пока я работал. - person SqlRyan; 03.11.2009
comment
К сожалению, простое удаление SCHEMABINDING с помощью оператора ALTER не будет работать для индексированных представлений, поэтому в этих случаях я считаю, что единственным решением остается отбросить и воссоздать представление. - person jpierson; 19.08.2010
comment
Я только что протестировал выполнение ALTER VIEW в своем индексированном представлении, чтобы увидеть, что произойдет. Я ожидал увидеть какую-то ошибку (в хорошем смысле типичную для SQL Server), но вместо этого он просто удалил мои индексы. Поэтому остерегайтесь использования ALTER в представлении, чтобы изменить, привязано ли оно к схеме или нет, не зная, есть ли у него в первую очередь индексы. - person jpierson; 19.08.2010
comment
Если вы удалите привязку схемы (вам нужно использовать alter, который полностью перестраивает представление), у вас все равно не будет индекса, поэтому да, если вы добавите привязку схемы, вам придется воссоздать индекс. - person JeffO; 19.08.2010

arrow_upward
2
arrow_downward

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

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

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

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

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

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

person JonnyRaa    schedule 09.04.2014

arrow_upward
1
arrow_downward

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

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.

Мне как бы нужны мои ЛЕВЫЕ соединения. Этот вопрос SO актуален.

person ZagNut    schedule 04.03.2015

arrow_upward
1
arrow_downward

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

person Marcelo Barbieri    schedule 17.02.2016

arrow_upward
1
arrow_downward

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

person Mojave Green Rattlesnake-5959    schedule 19.02.2016

arrow_upward
0
arrow_downward

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

person Adriaan Davel    schedule 10.11.2016