LINQ-to-SQL против хранимых процедур? [закрыто]


188

Я посмотрел пост «Руководство для начинающих по LINQ» здесь, на StackOverflow ( Руководство для начинающих по LINQ ), но у меня возник вопрос:

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

Итак, вопрос таков: для простого поиска данных, какой подход лучше, LINQ-to-SQL или хранимые процессы? Какие-то конкретные плюсы или минусы?

Спасибо.

Ответы:


192

Некоторые преимущества LINQ перед sprocs:

  1. Тип безопасности : я думаю, мы все это понимаем.
  2. Абстракция : это особенно верно для LINQ-to-Entities . Эта абстракция также позволяет платформе добавлять дополнительные улучшения, которыми вы можете легко воспользоваться. PLINQ - это пример добавления поддержки многопоточности в LINQ. Изменения кода минимальны, чтобы добавить эту поддержку. Было бы НАМНОГО сложнее сделать этот код доступа к данным, который просто вызывает sprocs.
  3. Поддержка отладки : я могу использовать любой отладчик .NET для отладки запросов. С sprocs вы не можете легко отлаживать SQL, и этот опыт в значительной степени связан с вашим поставщиком базы данных (MS SQL Server предоставляет анализатор запросов, но часто этого недостаточно).
  4. Независимость от поставщика : LINQ работает с большим количеством баз данных, и количество поддерживаемых баз данных будет только увеличиваться. Sprocs не всегда переносимы между базами данных из-за разного синтаксиса или поддержки функций (если база данных вообще поддерживает sprocs).
  5. Развертывание : другие уже упоминали об этом, но проще развернуть одну сборку, чем развернуть набор sprocs. Это также связано с № 4.
  6. Проще : вам не нужно изучать T-SQL для доступа к данным, а также не нужно изучать API доступа к данным (например, ADO.NET), необходимый для вызова sprocs. Это связано с № 3 и № 4.

Некоторые недостатки LINQ против sprocs:

  1. Сетевой трафик : sprocs должен только сериализовать sproc-имя и данные аргумента по сети, в то время как LINQ отправляет весь запрос. Это может быть очень плохо, если запросы очень сложны. Однако абстракция LINQ позволяет Microsoft улучшать это с течением времени.
  2. Менее гибкий : Sprocs может в полной мере использовать набор функций базы данных. LINQ имеет тенденцию быть более универсальным в своей поддержке. Это распространено в любой языковой абстракции (например, C # против ассемблера).
  3. Перекомпиляция : если вам нужно внести изменения в способ доступа к данным, вам нужно перекомпилировать, установить версию и заново развернуть сборку. Sprocs иногда позволяет администратору БД настраивать процедуру доступа к данным без необходимости что-либо повторно развертывать .

Безопасность и управляемость - это то, о чем спорят и люди.

  1. Безопасность . Например, вы можете защитить свои конфиденциальные данные, ограничив прямой доступ к таблицам, и добавить списки ACL в sprocs. С помощью LINQ, однако, вы можете ограничить прямой доступ к таблицам и вместо того, чтобы положить списки ACL на обновляемых таблицах взглядов для достижения аналогичного конца (предполагается , что ваша база данных поддерживают обновляемые представления).
  2. Управляемость : использование представлений также дает вам преимущество в защите вашего приложения от изменений схемы (например, нормализации таблиц). Вы можете обновить представление, не требуя изменения кода доступа к данным.

Раньше я был большим профессионалом, но я начинаю склоняться к LINQ как к лучшей альтернативе в целом. Если в некоторых областях sprocs явно лучше, то я, вероятно, все еще напишу sproc, но получу к нему доступ через LINQ. :)


33
«LINQ работает с большим количеством баз данных», но LINQTOSQL поддерживает только SQL Server.
РасселH

7
LINQ to Entities работает с Postgres и MySql в дополнение к MSSQL. Не уверен, но я думал, что прочитал, что есть что-то для Oracle вокруг.
bbqchickenrobot

У devart dotConnect есть Oracle, но он чертовски глючит. Кроме того, я не могу преодолеть дефицит производительности, вызванный необходимостью выбора данных из базы данных для их обновления (Attach () также возможен, но довольно пуповато)
Эд Джеймс

5
Я не видел здесь никого, кто бы упоминал повторное использование кода. Вы не можете повторно использовать linq в приложениях VB6, asp или file maker pro. Если вы поместите что-то в базу данных, то это может быть использовано ВЕЗДЕ. Я думаю, вы могли бы сделать dll с linq, но это становится слишком сложным и дерьмовым imo. Добавить функцию или хранимую процедуру, которую можно использовать повторно, намного проще.
MikeKulls

Говоря о повторном использовании кода в TSQL (1), удачи в попытке сохранить результаты хранимой процедуры во временную таблицу, не прибегая к динамическому sql. (2) Вы мало что можете сделать, чтобы организовать все ваши функции / функции; пространство имен быстро захламляется. (3) Вы написали мощный оператор выбора, но теперь хотите, чтобы пользователь мог выбирать сортируемый столбец - в TSQL вам, возможно, придется использовать CTE, который делает row_number для каждого столбца, который может быть отсортирован; в LINQ это можно решить с помощью нескольких ifутверждений в запоздалой мысли.
Резервные байты

77

Как правило, я сторонник того, чтобы помещать все в хранимые процедуры, по всем причинам, по которым администраторы базировались годами. В случае с Linq верно то, что с простыми запросами CRUD не будет разницы в производительности.

Но имейте в виду несколько вещей при принятии этого решения: использование любого ORM тесно связывает вас с вашей моделью данных. Администратор баз данных не имеет свободы вносить изменения в модель данных, не заставляя вас изменять скомпилированный код. С помощью хранимых процедур вы можете скрыть такого рода изменения в некоторой степени, поскольку список параметров и набор (ы) результатов, возвращаемые из процедуры, представляют ее контракт, а внутренние параметры можно изменять, лишь бы этот контракт все еще выполнялся. ,

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

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

Возможно, гибридный подход был бы хорош с Linq? Конечно, Linq можно использовать для вызова хранимых процедур.


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

19
«Администратор базы данных не может свободно вносить изменения в модель данных, не заставляя вас изменять скомпилированный код». Почему вы защищаете это? Никто не должен иметь «свободу» вносить изменения, вот в чем смысл управления конфигурацией. Изменения должны пройти через dev, test и т. Д. Перед развертыванием.
Нил Барнвелл

6
@Neil: Да, но он не может вносить изменения в среду разработки, не заставляя разработчика изменять код.
Адам Робинсон

37
Я должен сказать, что много видел аргумент о тесной связи с базами данных, и я не уверен, что это так. Я никогда не сталкивался с ситуацией (кроме тривиальных примеров), когда я хочу изменить базу данных, которая не требует изменения кода выше. И действительно, чем Linq отличается от хранимых процедур или параметризованных запросов? Ваш уровень доступа к данным должен быть хорошо отделен и независимо от того, используете ли вы ORM или что-то более простое. Это то, что дает вам слабую связь, а не то, какую технологию вы используете. Просто мой 2с
Саймон П Стивенс

7
Я видел 199 хранимых процедур, написанных без необходимости для каждого 1 изменения схемы, которое было защищено от приложений посредством подписи SP, но, как сказал Саймон П. Стивенс, семантические изменения в использовании SP требовали, чтобы приложение изменило 100% приложений. время в любом случае. Не говоря уже о том факте, что само существование SP просто требует от будущего разработчика или dba утечки бизнес-логики в SP. Потом немного больше и немного больше.

64

Linq to Sql.

Сервер Sql будет кешировать планы запросов, поэтому для sprocs нет прироста производительности.

Ваши операторы linq, с другой стороны, будут логически частью и проверены с вашим приложением. Sprocs всегда немного отделены друг от друга и их сложнее поддерживать и тестировать.

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


8
Я не согласен с вашими комментариями по поводу выгоды от sprocs. Я представил ряд подходов к доступу к SQL Server в системе prod, и использование сохраненных процедур Prepare + показало одни из лучших результатов. Даже через несколько вызовов одной и той же логики. Возможно, вы правы в отношении БД с низким уровнем использования.
ториальную

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

5
@RussellH: Это было верно для .Net 3.5, они исправили это в .Net 4 (как для L2S, так и для L2E)
BlueRaja - Дэнни Пфлюгофт

3
@ Киет Не тот случай! В Linq создано гораздо больше планов выполнения, чем в SP. Преимущества существуют с кодом для отладки; но проблемы с перекомпиляцией для цикла развертывания компании; негибкость для проверки различных запросов ACTION, WHERE, ORDER BY. Изменение порядка оператора WHERE может привести к обработке другого запроса; упреждающее чтение; это не может быть легко сделано в Linq. Нужно иметь слой данных для настройки. ИП сложнее поддерживать и тестировать? Если вы не привыкли к этому; но SP полезны для корпусов и VLDB, высокой доступности и т. д.! Linq для небольших проектов, сольных работ; Действуй.
SnapJag

4
@SnapJag - Вы правы, что sprocs дает вам более точный контроль зерна, но факт в том, что в 99% случаев (даже в крупных корпоративных системах, в которых я работаю) вам не нужна дополнительная оптимизация. Sprocs сложнее поддерживать и тестировать, привыкли ли вы к ним или нет - я к ним очень привык (я был администратором баз данных, прежде чем я был разработчиком) и гарантирую, что sproc для каждой операции CRUD для нагрузок разных таблиц до настоящего времени это боль. Лучшая практика (IMHO) - программировать наиболее простым способом, а затем запускать проверки производительности и оптимизировать только там, где это необходимо.
Кит

40

Для получения основных данных я бы пошел на Linq без колебаний.

После перехода в Linq я обнаружил следующие преимущества:

  1. Отладка моего DAL никогда не была проще.
  2. Скомпилируйте безопасность времени, когда ваша схема изменится, бесценно.
  3. Развертывание проще, потому что все скомпилировано в DLL. Больше не нужно управлять сценариями развертывания.
  4. Поскольку Linq может поддерживать запросы ко всему, что реализует интерфейс IQueryable, вы сможете использовать тот же синтаксис для запроса XML, объектов и любых других источников данных без необходимости изучать новый синтаксис

1
для меня безопасность времени компиляции - это ключ!
bbqchickenrobot

Однако для развертывания, если вы работаете в корпоративной команде с циклом развертывания и существует ошибка, которая должна быть быстро устранена, ваше развертывание библиотек DLL с помощью QA и т. Д., Вероятно, является более строгим, чем путь к развертыванию одной базы данных. скрипт. Ваши преимущества, кажется, лучше представляют сценарий небольшой команды / проекта.
SnapJag

3
Развертывание сценариев SQL, которые не должны проходить через QA, не обязательно является хорошей вещью здесь.
Лян

27

LINQ будет раздувать кеш процедур

Если приложение использует LINQ to SQL, а в запросах используются строки, длина которых может сильно варьироваться, кэш процедур SQL Server будет раздутым с одной версией запроса для каждой возможной длины строки. Например, рассмотрим следующие очень простые запросы, созданные для таблицы Person.AddressTypes в базе данных AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Если оба этих запроса будут выполнены, мы увидим две записи в кэше процедур SQL Server: одна связана с NVARCHAR (7), а другая - с NVARCHAR (11). Теперь представьте, были ли сотни или тысячи различных входных строк, все с различной длиной. Кэш процедур станет излишне заполненным различными планами для одного и того же запроса.

Подробнее здесь: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290


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

6
@ Джон, это не поможет, если вы используете валидатор вместо литеральной строки, так как в конце вы отправляете литеральную строку в базу данных. это может выглядеть как переменная в вашем коде, но это будет строка в сгенерированном T-SQL, которая отправляется в БД.
kay.one

15
SQLMenace: согласно странице, на которую вы ссылаетесь, проблема решена в VS2010.
Марк Байерс

8
Эта проблема была действительной, когда ответ был опубликован, но с тех пор он был решен в VS2010, поэтому он больше не является проблемой.
Brain2000

17

Я думаю, что аргумент pro LINQ, похоже, исходит от людей, у которых нет истории разработки баз данных (в целом).

Особенно если использовать такой продукт, как VS DB Pro или Team Suite, многие из приведенных здесь аргументов неприменимы, например:

Сложнее в обслуживании и тестировании: VS обеспечивает полную проверку синтаксиса, проверку стиля, проверку ссылок и ограничений и многое другое. Он также предоставляет все возможности модульного тестирования и инструменты рефакторинга.

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

Отладка проще в LINQ: почему? VS позволяет полный переход от управляемого кода и регулярную отладку SP.

Скомпилирован в одну DLL, а не в сценарии развертывания. Еще раз, VS приходит на помощь, где он может создавать и развертывать полные базы данных или вносить изменения в безопасные данные.

Не нужно изучать TSQL с помощью LINQ. Нет, не нужно, но вы должны изучать LINQ - в чем выгода?

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

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

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

РЕДАКТИРОВАТЬ: сторона вещей, связанных с хранимыми процедурами LINQ to SQL - это то, о чем мне еще нужно почитать - в зависимости от того, что я найду, я могу изменить вышеупомянутую диатрибу;)


4
Изучать LINQ не составляет большого труда - это просто синтаксический сахар. TSQL - это совершенно другой язык. Яблоки и апельсины.
Адам Лассек

3
Преимущество изучения LINQ заключается в том, что он не привязан к какой-либо одной технологии - семантика запросов может использоваться для XML, объектов и т. Д., И со временем это будет расширяться.
Дейв Р.

5
Согласовано! Так много людей (разработчиков) ищут «быстрое продвижение» решения в небольших командах и проектах. Но если разработка перейдет на следующий уровень корпоративного стиля с несколькими командами, большими базами данных, большими объемами, высокой доступностью, распределенными системами, использование LINQ будет другой историей! Я не верю, что вам нужно будет слишком долго редактировать свое мнение. LINQ не предназначен для проектов / групп, которые больше по размеру и имеют несколько человек, несколько групп (Dev & DBA) и имеют строгий график развертывания.
SnapJag

17

LINQ является новым и имеет свое место. LINQ не изобретен, чтобы заменить хранимую процедуру.

Здесь я остановлюсь на некоторых мифах о производительности и CONS, только для «LINQ to SQL», конечно, я могу быть совершенно неправ ;-)

(1) Люди говорят, что LINQ-статистика может «кэшироваться» на SQL-сервере, поэтому она не теряет производительность. Частично верно. «LINQ to SQL» - это среда выполнения, переводящая синтаксис LINQ в статистику TSQL. Таким образом, с точки зрения производительности, жестко закодированный оператор ADO.NET SQL не имеет различий, чем LINQ.

(2) В качестве примера пользовательский интерфейс службы поддержки клиентов имеет функцию «переноса счета». сама эта функция может обновлять 10 таблиц БД и возвращать некоторые сообщения за один раз. С помощью LINQ вы должны создать набор операторов и отправить их как один пакет на сервер SQL. производительность этого переведенного пакета LINQ-> TSQL едва ли может соответствовать хранимой процедуре. Причина? поскольку вы можете настроить наименьшую единицу оператора в хранимой процедуре с помощью встроенного средства профилирования SQL и инструмента плана выполнения, вы не сможете сделать это в LINQ.

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

(3) «LINQ to SQL» легко заставляет новичков вводить скачки производительности. Любой старший по TSQL может сказать вам, когда не следует использовать CURSOR (в большинстве случаев вам не следует использовать CURSOR в TSQL). С LINQ и очаровательным циклом «foreach» с запросом новичку так легко написать такой код:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Вы можете видеть, что этот простой приличный код настолько привлекателен. Но под капотом .NET runtime просто переводит это в пакет обновления. Если есть только 500 строк, это 500 строк TSQL-пакета; Если есть миллионы строк, это хит. Конечно, опытный пользователь не будет использовать этот способ для выполнения этой работы, но дело в том, что так легко упасть таким образом.


2
легко указывать ошибки в C / C ++ / C # означает ли это, что его никогда не следует использовать?
bbqchickenrobot

1
Сколько программистов среднего уровня имеют дело с указателями? Linq предоставляет эту возможность любому кодировщику уровня, что значительно увеличивает риск ошибки.
Жак

1
Вы сравниваете новичков в LINQ со старшим парнем из TSQL. Не совсем честное сравнение. Я согласен с вашим кодом, LINQ вообще не подходит для пакетного обновления / удаления. Тем не менее, я бы сказал, что большинство аргументов производительности между LINQ и SP, являются претензиями, но не основаны на измерении
Лян

12

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


10

LINQ определенно имеет свое место в специфичных для приложений базах данных и в малых предприятиях.

Но в большом предприятии, где центральные базы данных служат центром общих данных для многих приложений, нам нужна абстракция. Нам необходимо централизованно управлять безопасностью и показывать историю доступа. Нам нужно уметь анализировать влияние: если я внесу небольшое изменение в модель данных, чтобы удовлетворить новые потребности бизнеса, какие запросы необходимо изменить и какие приложения необходимо повторно протестировать? Представления и хранимые процедуры дают мне это. Если LINQ сможет сделать все это и сделать наших программистов более продуктивными, я приветствую это - есть ли у кого-нибудь опыт использования этого в такой среде?


2
Вы подняли хорошую мысль; LINQ не является альтернативой в этом случае.
Мета-Рыцарь

1
Все ваши различные приложения должны использовать общий уровень доступа к данным (конечно, это не всегда так). Если так, то вы можете внести одно изменение в общую библиотеку и повторно развернуть ее. Вы также можете использовать что-то вроде WCF для обработки доступа к данным для вас. Есть хороший уровень абстракции, который технически может использовать linq для доступа к данным за кулисами. Я думаю, все зависит только от того, что ваши парни придумали для ваших требований в отношении использования SP против Linq.
bbqchickenrobot

8

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

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


7

ИМХО, RAD = LINQ, RUP = сохраненные процессы. Я много лет работал в крупной компании Fortune 500, на многих уровнях, включая менеджмент, и, честно говоря, я бы никогда не нанял разработчиков RUP для разработки RAD. Они настолько обособлены, что очень ограничены в знаниях о том, что делать на других уровнях процесса. В изолированной среде имеет смысл предоставить администраторам БД контроль над данными через очень специфические точки входа, потому что другие, откровенно говоря, не знают наилучших способов управления данными.

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

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


3
Да, мы, администраторы баз данных, весь день ждем, пока вы запросите продвижение Stored Proc в производство. Отсутствие необходимости в этом разбило бы наши сердца!
Сэм

6

Я думаю, что вы должны пойти с процессами для чего-то реального.

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

Б) Я не уверен, что моделирование объектов в любом случае лучше, чем реляционное моделирование.

C) Тестирование и разработка хранимой процедуры в SQL - это намного быстрее, чем цикл редактирования компиляции в любой среде Visual Studio. Вы просто редактируете, F5 и нажимаете кнопку выбора, и вы отправляетесь в гонки.

D) Управлять и развертывать хранимые процедуры проще, чем сборки. Вы просто помещаете файл на сервер и нажимаете F5 ...

E) Linq to sql по-прежнему пишет дрянной код иногда, когда вы этого не ожидаете.

Честно говоря, я думаю, что в конечном итоге MS мог бы увеличить t-sql, чтобы он мог имплицитно проецировать соединение, как это делает linq. t-sql должен знать, если вы хотите сделать, например, order.lineitems.part.


5

LINQ не запрещает использование хранимых процедур. Я использовал смешанный режим с LINQ-SQL и LINQ-storeproc . Лично я рад, что мне не нужно писать сохраненные процы .... pwet-tu.


4

Также существует проблема возможного отката 2.0. Поверьте мне, это случилось со мной пару раз, поэтому я уверен, что это случилось с другими.

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


3

Я предполагаю, что вы имеете в виду Linq To Sql

Для любой команды CRUD легко профилировать производительность хранимой процедуры по сравнению с любой технологией. В этом случае любая разница между ними будет незначительной. Попробуйте профилировать для объекта поля 5 (простых типов) более 100 000 запросов на выборку, чтобы выяснить, есть ли реальная разница.

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


1
Поскольку больше данных, чем приложение, может повлиять на данные - импорт данных, другие приложения, прямые запросы и т. Д., Глупо не помещать бизнес-логику в базу данных. Но если целостность данных вас не беспокоит, продолжайте.
HLGEM

3
Бизнес-логика не должна идти в базу данных. Это должно быть на языке программирования, где это легко отлажено и управляется. Затем он может быть разделен между приложениями как объекты. Некоторые правила могут быть в базе данных, но не в бизнес-логике.
пространство

3

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

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

Надеюсь, это поможет, я могу ошибаться. : D


1
друзья погибли, катаясь на мотоциклах: P
Alex

2
люди погибли за рулем автомобиля.
Лян

1
да вы не правы
Асад Али

3

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

Некоторые преимущества или Linq, я читал здесь как: простота тестирования, простота отладки и т. Д., Но они не связаны с конечным выходом или конечным пользователем. Это всегда вызывает проблемы у конечного пользователя по производительности. Какой смысл загружать много вещей в память, а затем применять фильтры при использовании LINQ?

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

Хотя мы обнаружили, что это хорошо, приятно, интересно и т. Д. При работе с LINQ, у него есть серьезный недостаток, заключающийся в том, что он делает разработчика ленивым :), и 1000 раз доказано, что это плохо (может быть хуже) по производительности по сравнению с Stored Procs.

Хватит лениться. Я стараюсь изо всех сил. :)


4
Загрузка всего в память и фильтрация? Linq может отправлять фильтр как часть запроса в базу данных и возвращает отфильтрованный набор результатов.
Лян

Есть немало людей, которые считают, что LINQ загружает все данные и обрабатывает их с помощью цикла foreach. Это неверно. Он просто компилируется в SQL-запрос и обеспечивает почти одинаковую производительность для большинства операций CRUD. Но да, это не серебряная пуля. Есть случаи, когда использование T-SQL или хранимых процедур может оказаться лучше.
Это ловушка

Я согласен с обоими контраргументами. Однако не совсем верно, что linq отправляет все фильтры в СУБД для работы над ней. Есть несколько вещей, которые работают в памяти, одна из них отличается.
Маниш

2

Для простых операций CRUD с одной точкой доступа к данным, я бы сказал, пойти на LINQ, если вы чувствуете себя комфортно с синтаксисом. Для более сложной логики я думаю, что sprocs более эффективны с точки зрения производительности, если вы хорошо разбираетесь в T-SQL и его более сложных операциях. У вас также есть помощь от Tuning Advisor, SQL Server Profiler, отладки ваших запросов из SSMS и т. Д.


2

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


1

Результат может быть обобщен как

LinqToSql для небольших сайтов и прототипов. Это действительно экономит время для прототипирования.

СПС: Универсальный. Я могу точно настроить свои запросы и всегда проверять ActualExecutionPlan / EstimatedExecutionPlan.



0

И LINQ, и SQL имеют свои места. Оба имеют свои недостатки и преимущества.

Иногда для сложного поиска данных вам могут понадобиться хранимые процедуры. Иногда вы можете захотеть, чтобы другие люди использовали ваш сохраненный процесс в Sql Server Management Studio.

Linq to Entities отлично подходит для быстрой разработки CRUD.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.