Вопрос по sql-server, c# – Использовать SQL View или SQL Query?

8

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

<code>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;
</code>

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

<code> CREATE VIEW V1 AS
   "SELECT T1.f1, ..."
</code>

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

<code> string query = "SELECT f1, f2, f3 FROM V1";
 ....
 cmd.CommandText = query;
</code>

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

Ваш Ответ

4   ответа
16

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

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

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

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

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

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

Недостатком является то, что вы должны развертывать и версировать свой вид синхронно с клиентским кодом. Brian Reiter
@ RBarryYoung: правильно. @James Вид - это макрос, не больше, не меньше. Оптимизатор расширяет / удаляет его, и вы получите тот же план. gbn
вздо Представления НЕ работают быстрее, чем запросы. Представления и запросы разрешают одно и то же. RBarryYoung
Я бы не стал давать этот общий совет. Представление отлично подходит для распространенных запросов, но оно никогда не должно быть первым ответом. Я видел множество БД с 300 представлениями и (ненужными) представлениями поверх представлений, потому что «Представления выполняются быстрее!» Это правда только если вы используете представленияЧто . Просто соблюдайте осторожность при построении представлений. Eric
@ Брайан: вам нужно беспокоиться о синхронизации, только если вы удаляете столбец или что-то еще. Если вы добавляете, вам не нужно беспокоиться об этом, и вы можете полностью изменить реализацию до тех пор, пока возвращаются хотя бы исходные столбцы. На самом деле это не так уж и плохо, как будто вы вносите изменения, которые в значительной степени изменяются, вероятно, в любом случае ... CodeRedick
2

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

3

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

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

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

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

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

2

яется поистине гигантским и не требует затрат).

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