Есть ли проблема с производительностью при использовании встроенных операторов SQL, а не при использовании DAL?

Question

Я сделал довольно большой веб-сайт типа социальной сети и использовал только встроенные операторы SQL для доступа к базе данных (я был новичком в языке, поэтому отступайте!)

Существуют ли какие-либо проблемы с производительностью при выполнении этого способа, в отличие от использования массивного файла XSD DataSet для обработки всех запросов? Или это просто плохой дизайн?

Спасибо!

Answer 1

Когда вы сталкиваетесь с реальными проблемами производительности БД, на самом деле не имеет значения (с точки зрения производительности), используете ли вы хранимые процедуры или прямые операторы SQL.

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

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

Answer 2

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

Answer 3

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

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

Answer 4

При большом объеме данных БД лучше в отношении: обслуживания и производительности. Например, наличие хранимых процедур позволяет делегировать работу и оптимизацию запросов профессиональному администратору базы данных, перекомпиляции не требуется. При наличии файлов данных XSD / XML вы должны заново генерировать свой код для каждого изменения.

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

Answer 5

Держитесь подальше от сгенерированных типизированных наборов данных. Производительность не так хороша. Если вам нужен тип функциональности, посмотрите на LINQ; в противном случае просто возьмите Enterprise Library и идите прямо.

Answer 6

Строго говоря, производительность SQL была бы лучше, если бы вы использовали встроенные операторы SQL вместо набора данных XSD. Это предполагает, что как минимум вы используете параметризованные запросы (хотя SQL Server 2005 даже оптимизирует для не параметризованных запросов).

Утверждение, что встроенный sql не может быть оптимизирован ядром базы данных, неверно. Хранимые процедуры оптимизированы идентично встроенному SQL с SQL Server.

Но имеет ли это смысл с точки зрения дизайна - это совсем другая история. А слишком ли вы слишком оптимистичны - это другой вопрос.