Использовать SQL View или SQL Query?

Question

Я работаю над приложением для получения данных с сервера MS-SQL (2005). В тексте команды я могу передать SQL-запрос следующим образом:

string query = "SELECT T1.f1, T1.f2, T2.f3 FROM table1 T1 join table2 T2" +
   "on T1.id = T2.id AND T1.dt = T2.dt ..."
....
cmd.CommandText = query;

Я также мог бы разместить запрос в виде представления на моем SQL-сервере следующим образом:

 CREATE VIEW V1 AS
   "SELECT T1.f1, ..."

Тогда я могу использовать представление в упрощенном запросе, например:

 string query = "SELECT f1, f2, f3 FROM V1";
 ....
 cmd.CommandText = query;

Я не уверен, какой путь лучше. Будет ли представление быстрее, чем SQL-запрос? Кстати, запрос, который я здесь показываю, является упрощенным. Фактический запрос SELECT является более сложным.

Answer 1

Я бы создал VIEW по нескольким причинам

A) Хорошо построенное представление, как правило, работает быстрее, чем запрос, хотя при оптимизации запроса вы можете не заметить большой разницы.

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

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

ПОПРАВКА Я собираюсь изменить этот ответ в свете некоторых комментариев, чтобы уточнить некоторые моменты ...

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

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

Answer 2

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

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

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

Вам также следует рассмотреть какую-то технологию ORM (Object Relational Mapper), такую ​​как LINQ to SQL (L2S). Это позволяет вам использовать SQL-подобные запросы в вашем коде, но все абстрагируется через объекты, созданные в конструкторе L2S.

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

Answer 3

Разницы в производительности нет (если только текст SQL-запроса не является поистине гигантским и не требует затрат).

Answer 4

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

Answer 5

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

Реальная разница и ценность Views заключается в том, что, подобно функциям и подпрограммам, они могут использоваться повторно .

Answer 6

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

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

Answer 7

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

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

Answer 8

Вид, вероятно, лучше.

Таким образом, вы можете изменить запрос (для оптимизации) на более поздний срок без необходимости изменения кода.

Answer 9

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

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

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