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

Question

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

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

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

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

Answer 1

Есть несколько очень хороших применений для представлений; Я много их использовал для настройки и предоставления менее нормализованных наборов информации или для объединения результатов нескольких выборок в один набор результатов.

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

Между прочим, я никогда не был поклонником архитектурных "правил", которые основаны на том, чтобы не причинять вред разработчикам. Эти правила часто имеют непреднамеренные побочные эффекты - последнее место, где я работал, не позволяло использовать NULL в базе данных, потому что разработчики могут забыть проверить нулевое значение. Это привело к тому, что мы вынуждены работать с датами и целыми числами «01.01.1900» по умолчанию «0» во всем программном обеспечении, построенном для баз данных, и вводить множество ошибок, вызванных разработчиками, работающими в местах, где NULL было подходящим значением. .

Answer 2

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

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

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

Answer 3

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

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

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

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

Как и BlaM, лично я не нашел их проще в обслуживании, чем хранимые процы.

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

Answer 4

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

Answer 5

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

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

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

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

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

Answer 9

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

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

Answer 10

С точки зрения приложения, которое использует ORM, выполнить пользовательский запрос намного сложнее, чем выполнить выборку для дискретно отображаемого типа (например, представления).

Например, если вам нужно всего 5 полей таблицы, в которой много (скажем, 30 или 40), среда ORM создаст объект для представления таблицы.

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

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

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

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

Хотя этот подход хорош и, безусловно, дает результат, он имеет много отрицательных аспектов. Ручной код ... является ручным; сложный в обслуживании, громоздкий в реализации и заставляющий разработчиков больше беспокоиться о специфике API провайдера БД по сравнению с моделью логического домена. Не говоря уже о том, что это увеличивает время производства (его гораздо более трудоемкие) затраты на разработку, обслуживание, площадь поверхности ошибок и т. Д.

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