Представления SQL Server, благословение или проклятие?

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

База данных имела почти 600 таблиц и была высоко нормализована, таким образом, большая часть полезного SQL была обязательно подробной.

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

Задним числом я сказал бы, что это было плохое решение, но каков Ваш опыт с представлениями SQL? Вы нашли их плохо для производительности? Какие-либо другие мысли о том, когда они или не являются соответствующими?

28
задан Rod Argumedo 20 September 2019 в 14:37
поделиться

0 ответов

Существует некоторое очень хорошее использование для представлений; я использовал их много для настройки и для представления менее нормализованных наборов информации, или для луга ОБЪЕДИНЕНИЯ следует из нескольких выборов в единственный набор результатов.

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

Кстати, я никогда не был поклонником архитектурных "правил", которые основаны на мешающих разработчиках причинить себе боль. Эти правила часто имеют непреднамеренные побочные эффекты - последнее место, я работал, не позволил использовать, АННУЛИРУЕТ в базе данных, потому что разработчики могли бы забыть проверять на пустой указатель. Это закончило тем, что вынудило нас работать вокруг "1/1/1900" дат, и целые числа приняли значение по умолчанию к "0" во всем программном обеспечении, созданном против баз данных, и представить унылый перечень ошибок, вызванных devs, работающим вокруг мест, где ПУСТОЙ УКАЗАТЕЛЬ был соответствующим значением.

31
ответ дан Guy Starbuck 28 November 2019 в 02:29
поделиться

Вы ответили на свой собственный вопрос:

он поощрял повторное использование кода с помощью копии-и-вставки

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

20
ответ дан Tyler Gooch 28 November 2019 в 02:29
поделиться

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

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

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

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

Как BlaM я лично не нашел их легче поддержать, чем сохраненный procs.

Отредактированный в октябре 2010 для добавления: Так как я orginally записал это, у меня был случай для работы с несколькими базами данных, разработанными людьми, которые увлеклись использованием представлений. Еще хуже они использовали представления, которые назвали представления, которые назвали представления (к точке, где в конечном счете мы поражаем предел количества таблиц, которые можно назвать). Это было кошмаром производительности. Потребовалось 8 минут, чтобы получить простое количество (*) записей в одном представлении и намного дольше получить данные. Если Вы используете представления, очень опасаются использовать представления, которые называют другие представления. Вы будете создавать систему, которая не будет очень, вероятно, работать при нормальной нагрузке производительности на производство. В SQL Server можно только индексировать представления, которые не называют другие представления, поэтому что заканчивает тем, что произошло, когда Вы используете представления в цепочке, то, что весь официальный набор документов должен быть создан для каждого представления и только когда Вы добираетесь до последнего, где критерии пункта применяются. Вы, возможно, должны генерировать миллионы записей только для наблюдения три. Можно соединить с теми же временами таблицы 6, когда действительно только необходимо соединить с ним однажды, можно возвратить еще много столбцов, чем Вам нужно в наборе конечных результатов.

17
ответ дан HLGEM 28 November 2019 в 02:29
поделиться

Моя текущая база данных была абсолютно наводнена бесчисленными маленькими таблицами не больше, чем 5 строк каждый. Ну, я мог считать их, но это было нарушено. Эти таблицы просто содержали постоянные значения типа (думайте перечисление), и мог очень легко быть объединен в одну таблицу. Я тогда сделал представления, которые моделировали каждую из таблиц, которые я удалил для обеспечения обратной уплотняемости. Работавший отлично.

5
ответ дан Craig 28 November 2019 в 02:29
поделиться

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

Это имеет два достоинства:

  1. , Чтобы позволить пользователю единственным "таблицам", содержащим данные, они ожидают довольно требующий относительно не технические пользователи разрабатывать потенциально сложные соединения (потому что база данных нормализована)
  2. , Это обеспечивает средство позволить определенную степень ах hoc доступ, не представляя данные или структуру конечным пользователям.

Даже со специальным созданием отчетов об иногда signicantly легче предоставить представление системе отчетности, которая содержит relveant данные, аккуратно разделяя производство данных из представления того же.

4
ответ дан Murph 28 November 2019 в 02:29
поделиться

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

4
ответ дан Jakub Šturc 28 November 2019 в 02:29
поделиться

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

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

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

3
ответ дан Eric Z Beard 28 November 2019 в 02:29
поделиться

Мы используем представления для всего нашего простого экспорта данных в файлы CSV. Это упрощает процесс записи пакета и встраивания sql в пакете, который становится громоздким и твердым отладить против.

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

1
ответ дан Sean Chambers 28 November 2019 в 02:29
поделиться

Некоторое время назад я попытался поддержать код, который использовал представления, созданные из представлений, созданных из представлений... Это было болью в **, таким образом, я стал немного аллергическим на представления:)

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

Однако, который не исключает представления полностью, если используется соответственно. Например, можно использовать представление с "пользовательской" таблицей, к которой присоединяются с "users_status" таблицей для получения текстового объяснения каждого состояния - при необходимости в нем. Однако, если Вам не нужно объяснение: используйте "пользовательскую" таблицу, не представление. Как всегда: Используйте мозг!

1
ответ дан BlaM 28 November 2019 в 02:29
поделиться

Давайте посмотрим, могу ли я придумать хромую аналогию...

"Мне не нужна крестообразная отвертка. Я несу плоскую головку и шлифовальный станок!"

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

0
ответ дан Niniki 28 November 2019 в 02:29
поделиться
Другие вопросы по тегам:

Похожие вопросы: