Использовать представление SQL или SQL-запрос?

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

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

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

Views aren't a performance feature. They exist to reduce the number of joins and to allow you to denormalize without actually denormalizing.

In other words, use whichever makes your code the simplest and don't change for performance reasons unless you have good reason to do so. These kinds of optimizations usually aren't worth it.

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

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

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

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

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

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

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

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

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

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

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

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

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