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

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

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

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

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

Ответ 1

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

Ответ 9

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

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

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

Ответ 10

Посмотрим, смогу ли я придумать хромую аналогию...

"Мне не нужна крестовая отвертка. Я несу плоскую головку и мясорубку!"

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

Ответ 11

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

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

Ответ 12

Представления также могут уменьшить размер сложных запросов (так же, как хранится процесс procs).

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

Ответ 13

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

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

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

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

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

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

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

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