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

Question

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

Answer 1

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

Answer 3

Если вы заинтересованы в бенчмаркинге, Rico Mariani предлагает превосходное исследование из 5 частей , которое охватывает качественные и количественные различия.

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

Answer 4

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

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

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

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

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

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

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

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