Обеспечивает ли LINQ To SQL более быстрое время отклика, чем использование ado.net и oledb?

Question

LINQ, несомненно, упрощает программирование баз данных, но есть ли у него обратная сторона?Встроенный SQL требует, чтобы пользователь взаимодействовал с базой данных определенным образом, который открывает базу данных для инъекций.Встроенный SQL также должен быть проверен на синтаксис, иметь построенный план и затем выполняться, что требует драгоценных циклов.Хранимые процедуры также были незыблемым стандартом в прикладном программировании больших баз данных.Многие программисты, которых я знаю, используют уровень данных, который, однако, упрощает разработку не в такой степени, как LINQ.Не пора ли отказаться от SP и перейти на LINQ?

Answer 1

LINQ to SQL на самом деле создает некоторые тревожные проблемы с производительностью базы данных.По сути, он создает несколько планов выполнения в зависимости от длины используемого вами параметра.Некоторое время назад я писал об этом в своем блоге ССЫЛКА на SQL может вызвать проблемы с производительностью.

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

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

Как и в большинстве решений для баз данных, правильный ответ зависит от проблемы, которую вы пытаетесь решить.Если вы предпочитаете скорость разработки производительности базы данных / приложения, то лучше всего использовать LINQ или другой инструмент DAL / ORM.Если вы предпочитаете производительность простоте разработки, то использование хранимых процедур и чистых наборов данных будет вашим лучшим выбором.LLBLGen даже предоставляет LINQ для уровня LLBLGen, так что вы можете использовать LINQ для запроса объектов LLBLGen и заставить LLBLGen фактически обрабатывать построение ваших запросов и избегать некоторых недостатков LINQ.

Answer 2

Ваша основная предпосылка ошибочна..

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

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

Параметризация ваших запросов защищает от атак с использованием инъекций, но встроенный SQL можно параметризовать так же легко, как и хранимые процедуры.

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

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

Итак, если вы жестко закодируете значения во встроенный SQL, текст не будет совпадать, и ему придется повторно проанализировать запрос.Однако, если вы используете параметры, текст запроса будет совпадать, и вы получите попадание в кэш.В этом случае не имеет значения, выполняется ли запрос во встроенном SQL или SP.

Другими словами, единственная проблема со встроенным SQL заключается в том, что легко сделать что-то медленное и небезопасное.Но сделать встроенный SQL быстрым и безопасным - это не больше работы, чем с использованием SP.

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

LINQ также имеет преимущество перед SPS в том, что весь ваш код находится в одном месте, а не разбросан по двум разным машинам.

Answer 3

Если вы заинтересованы в бенчмаркинге, у Рико Мариани есть отличное исследование из 5 частей это охватывает качественные и количественные различия.

Может, он и специалист по MS, но он известен как помешанный на производительности - его тесты тщательны и хорошо продуманы.

Answer 4

Этим спектаклем руководит Максимилиан Беллер.По его словам, LINQ работает намного медленнее.Прочтите его всестороннее исследование

Answer 5

Просто подумайте об изменении названия столбцов - теперь измените (n) SPS и (x) представления.

Делайте все, что дорого, в базе данных (например, поиск, сортировку и т.д.), И вы не заметите проблемы.

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

StackOverflow также использует linq2sql - вы видите проблему :)?

Используйте ORM - это правильный путь для большинства приложений.

PS:кроме того, о микро-бенчмарках - вроде..давайте выберем 10.000 строк с помощью ORM - НЕ ДЕЛАЙТЕ ЭТОГО.Это не то, почему вы используете ORM.Если вы хотите выбрать 10 000 строк, используйте ADO.

Answer 6

Это зависит от того, что вы делаете.LINQ будет менее эффективен при фактических манипуляциях с данными / наборами, чем реальная база данных.Но вы значительно сэкономите, поскольку вам не придется подключаться к базе данных по сети.

Если ваша база данных находится на том же компьютере или формально "хорошо подключена", вам, вероятно, лучше использовать ее.

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

Answer 7

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

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

Это не значит, что вы не можете создать какой-то действительно не поддерживаемый код с помощью LINQ - никто не мешает вам прострелить себе ногу, кроме вас самих, - но при правильном выполнении LINQ может оказать огромную помощь.Однако я не говорю, что LINQ - это серебряная пуля.У него есть множество проблем, которые затрудняют его использование во многих корпоративных ситуациях - вот почему MS предлагает Entity Framework (ADO.NET 3.0).Конечно, даже это не идеально, учитывая недавний вотум недоверия EF.

Является ли LINQ для SQL или даже EF лучше, чем raw SQL?Я бы сказал, оглушительное, Черт возьми, "Да".Есть ли другие решения, которые могли бы работать лучше?Может быть.