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

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

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

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

Спасибо.

18.08.2008 12:37:57
23 ОТВЕТА
РЕШЕНИЕ

Некоторые преимущества 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. :)

191
26.08.2008 20:04:51
«LINQ работает с большим количеством баз данных», но LINQTOSQL поддерживает только SQL Server.
RussellH 24.12.2008 01:27:33
LINQ to Entities работает с Postgres и MySql в дополнение к MSSQL. Не уверен, но я думал, что прочитал, что есть что-то для Oracle вокруг.
bbqchickenrobot 8.07.2009 17:36:02
У devart dotConnect есть Oracle, но он чертовски глючит. Кроме того, я не могу преодолеть дефицит производительности, вызванный необходимостью выбора данных из базы данных для их обновления (Attach () также возможен, но довольно пуповато)
Ed James 2.03.2010 15:46:53
Я не видел здесь никого, кто бы упоминал повторное использование кода. Вы не можете повторно использовать linq в приложении VB6, asp или file maker pro. Если вы поместите что-то в базу данных, то это можно будет использовать ВЕЗДЕ. Я думаю, вы могли бы создать dll с linq, но это становится слишком сложным и дерьмовым imo. Добавить функцию или хранимую процедуру, которую можно использовать повторно, намного проще.
MikeKulls 9.03.2012 00:42:31
Говоря о повторном использовании кода в TSQL (1), удачи в попытке сохранить результаты хранимой процедуры во временную таблицу, не прибегая к динамическому sql. (2) Вы мало что можете сделать, чтобы организовать все ваши функции / функции; пространство имен быстро захламляется. (3) Вы написали мощный оператор выбора, но теперь вы хотите, чтобы пользователь мог выбирать сортируемый столбец - в TSQL вам, возможно, придется использовать CTE, который делает row_number для каждого столбца, который может быть отсортирован; в LINQ это можно решить с помощью нескольких ifутверждений в запоздалой мысли.
sparebytes 3.12.2013 17:07:52

Linq to Sql.

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

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

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

64
18.08.2008 12:46:04
Я не согласен с вашими комментариями по поводу выгоды от sprocs. Я представил ряд подходов к доступу к SQL Server в системе prod, и использование сохраненных процедур Prepare + показало одни из лучших результатов. Даже через несколько вызовов одной и той же логики. Возможно, вы правы в отношении БД с низким уровнем использования.
torial 20.10.2008 03:24:22
Если вы являетесь и будете самым опытным разработчиком запросов к базам данных, используйте то, что вам наиболее близко знакомо. В отличие от процедурного кода, вы не можете сказать «если он дает правильный ответ, отправьте его».
dkretz 3.12.2008 05:55:37
@RussellH: Это было верно для .Net 3.5, они исправили это в .Net 4 (как для L2S, так и для L2E)
BlueRaja - Danny Pflughoeft 4.05.2010 13:32:52
@ Киет Не тот случай! В Linq создано гораздо больше планов выполнения, чем в SP. Преимущества существуют с кодом для отладки; но проблемы с перекомпиляцией для цикла развертывания компании; негибкость для проверки различных запросов ACTION, WHERE, ORDER BY. Изменение порядка оператора WHERE может привести к обработке другого запроса; упреждающее чтение; это не может быть легко сделано в Linq. Нужно иметь слой данных, доступный для настройки. ИП сложнее поддерживать и тестировать? Если вы не привыкли к этому; но SP полезны для корпусов и VLDB, высокой доступности и т. д.! Linq для небольших проектов, сольных работ; Действуй.
SnapJag 28.07.2010 15:49:05
@SnapJag - Вы правы, что sprocs дает вам более точный контроль зерна, но факт в том, что в 99% случаев (даже в крупных корпоративных системах, в которых я работаю) вам не нужна дополнительная оптимизация. Sprocs сложнее поддерживать и тестировать, привыкли ли вы к ним или нет - я к ним очень привык (я был администратором баз данных, прежде чем я был разработчиком) и гарантирую, что sproc для каждой операции CRUD для нагрузок разных таблиц до настоящего времени это боль. Лучшая практика (IMHO) - программировать наиболее простым способом, а затем запускать проверки производительности и оптимизировать только там, где это необходимо.
Keith 29.07.2010 07:46:49

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

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

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

3
18.08.2008 12:44:12
Поскольку больше данных, чем приложение, может повлиять на данные - импорт данных, другие приложения, прямые запросы и т. Д., Глупо не помещать бизнес-логику в базу данных. Но если целостность данных не беспокоит вас, продолжайте.
HLGEM 11.11.2008 14:10:42
Бизнес-логика не должна идти в базу данных. Это должно быть на языке программирования, где это легко отлажено и управляется. Затем он может быть разделен между приложениями как объекты. Некоторые правила могут быть в базе данных, но не в бизнес-логике.
4thSpace 2.02.2009 06:46:20

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

12
18.08.2008 12:45:13

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

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

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

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

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

77
10.10.2008 15:40:11
Одной из особенностей, которой вы пренебрегали, является безопасность. С Linq вы должны выставлять таблицы непосредственно приложению. С помощью хранимых процедур вы можете ограничить доступ к этим процессам и обеспечить соблюдение бизнес-требований.
NotMe 26.11.2008 15:46:19
«Администратор базы данных не может свободно вносить изменения в модель данных, не заставляя вас изменять скомпилированный код». Почему вы защищаете это? Никто не должен иметь «свободу» вносить изменения, вот в чем смысл управления конфигурацией. Изменения должны пройти через dev, test и т. Д. Перед развертыванием.
Neil Barnwell 3.03.2009 17:22:09
@Neil: Да, но он не может вносить изменения в среду разработки, не заставляя разработчика изменять код.
Adam Robinson 15.04.2009 14:56:16
Я должен сказать, что много видел аргумент о тесной связи с базами данных, и я не уверен, что это так. Я никогда не сталкивался с ситуацией (за исключением тривиальных примеров), когда я хочу изменить базу данных, которая не требует изменения кода выше. И действительно, чем Linq отличается от хранимых процедур или параметризованных запросов? Ваш уровень доступа к данным должен быть хорошо отделен и независимо от того, используете ли вы ORM или что-то более простое. Это то, что дает вам слабую связь, а не то, какую технологию вы используете. Просто мой 2с
Simon P Stevens 19.06.2009 17:40:35
Я видел 199 хранимых процедур, написанных без необходимости для каждого 1 изменения схемы, которое было защищено от приложений посредством подписи SP, но, как сказал Саймон П. Стивенс, семантические изменения в использовании SP требовали, чтобы приложение изменило 100% приложений. время в любом случае. Не говоря уже о том, что само существование SP просто требует от будущего разработчика или dba утечки бизнес-логики в SP. Потом немного больше и немного больше.
user74754 24.07.2012 22:50:41

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

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

  1. Отладка моего DAL никогда не была проще.
  2. Скомпилируйте безопасность времени, когда ваша схема изменится, и это бесценно.
  3. Развертывание проще, потому что все скомпилировано в DLL. Больше не нужно управлять сценариями развертывания.
  4. Поскольку Linq может поддерживать запросы ко всему, что реализует интерфейс IQueryable, вы сможете использовать тот же синтаксис для запроса XML, объектов и любых других источников данных без необходимости изучения нового синтаксиса.
40
18.08.2008 13:08:31
для меня безопасность времени компиляции - это ключ!
bbqchickenrobot 8.07.2009 17:36:55
Однако для развертывания, если вы работаете в корпоративной команде с циклом развертывания и существует ошибка, которая должна быть быстро устранена, развертывание библиотек DLL через QA и т. Д., Вероятно, более строгое, чем путь к развертыванию одной базы данных. скрипт. Ваши преимущества, кажется, лучше представляют сценарий небольшой команды / проекта.
SnapJag 28.07.2010 15:56:14
Развертывание сценариев SQL, которые не должны проходить через QA, не обязательно является хорошей вещью здесь.
liang 14.05.2015 06:53:30

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

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

8
19.08.2008 14:28:23

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

5
28.08.2008 12:39:55

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

27
21.05.2015 23:29:14
Какой глупый аргумент - просто используйте переменную, и ваша проблема решена.
JohnOpincar 24.06.2009 01:27:12
@ Джон, это не поможет, если вы используете валидатор вместо литеральной строки, так как в конце вы отправляете литеральную строку в базу данных. это может выглядеть как переменная в вашем коде, но это будет строка в сгенерированном T-SQL, которая отправляется в БД.
kay.one 26.07.2009 23:42:17
SQLMenace: согласно странице, на которую вы ссылаетесь, проблема решена в VS2010.
Mark Byers 7.04.2010 11:47:18
Эта проблема была действительной, когда ответ был опубликован, но с тех пор он был решен в VS2010, поэтому он больше не является проблемой.
Brain2000 6.12.2011 18:45:53

Хранимые Procs против кода (Предыдущее обсуждение)

2
23.05.2017 10:31:02

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

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

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

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

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

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

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

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

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

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

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

17
12.09.2008 04:42:23
Изучать LINQ не составляет большого труда - это просто синтаксический сахар. TSQL - это совершенно другой язык. Яблоки и апельсины.
Adam Lassek 9.10.2008 15:04:12
Преимущество изучения LINQ заключается в том, что он не привязан к какой-либо одной технологии - семантика запросов может использоваться для XML, объектов и т. Д., И со временем это будет расширяться.
Dave R. 18.12.2008 16:33:04
Согласовано! Так много людей (разработчиков) ищут «быстрое продвижение» решения в небольших командах и проектах. Но если разработка будет переведена на следующий уровень корпоративного стиля с несколькими командами, большими базами данных, большими объемами, высокой доступностью, распределенными системами, использование LINQ будет другой историей! Я не верю, что вам нужно будет слишком долго редактировать свое мнение. LINQ не предназначен для проектов / групп, которые больше по размеру и имеют несколько человек, несколько групп (Dev & DBA) и имеют строгий график развертывания.
SnapJag 28.07.2010 16:02:24

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

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

10
9.10.2008 14:43:53
Вы подняли хорошую мысль; LINQ не является альтернативой в этом случае.
Meta-Knight 8.06.2009 19:34:41
Все ваши различные приложения должны использовать общий уровень доступа к данным (конечно, это не всегда так). Если так, то вы можете внести одно изменение в общую библиотеку и повторно развернуть ее. Вы также можете использовать что-то вроде WCF для обработки доступа к данным для вас. Есть хороший уровень абстракции, который технически может использовать linq для доступа к данным за кулисами. Я думаю, все зависит только от того, что ваши парни придумали для ваших требований в отношении использования SP против Linq.
bbqchickenrobot 8.07.2009 18:25:57

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

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

4
21.03.2019 06:46:15

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-пакета; Если есть миллионы строк, это хит. Конечно, опытный пользователь не будет использовать этот способ для выполнения этой работы, но дело в том, что так легко упасть таким образом.

17
3.12.2008 05:40:53
легко указывать ошибки в C / C ++ / C # означает ли это, что его никогда не следует использовать?
bbqchickenrobot 8.07.2009 18:27:41
Сколько программистов среднего уровня имеют дело с указателями? Linq предоставляет эту возможность любому кодировщику уровня, что значительно увеличивает риск ошибки.
Jacques 18.03.2011 09:09:11
Вы сравниваете новичков в LINQ со старшим парнем из TSQL. Не совсем честное сравнение. Я согласен с вашим кодом, LINQ вообще не подходит для пакетного обновления / удаления. Тем не менее, я бы сказал, что большинство аргументов производительности между LINQ и SP являются претензиями, но не основаны на измерении
liang 14.05.2015 06:34:06

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

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

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

7
30.06.2009 19:04:17
Да, мы, администраторы баз данных, весь день ждем, пока вы запросите продвижение Stored Proc в производство. Отсутствие необходимости разрушит наши сердца!
Sam 24.02.2011 21:00:28

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

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

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

3
7.06.2011 07:53:56
друзья погибли на мотоциклах: P
Alex 24.07.2012 22:28:38
люди погибли за рулем автомобиля.
liang 14.05.2015 05:29:20
да вы не правы
Asad Ali 22.03.2017 15:40:06

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

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

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

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

0
12.08.2011 15:34:50

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

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

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

1
24.08.2011 04:30:03
Create PROCEDURE userInfoProcedure
    -- Add the parameters for the stored procedure here
    @FirstName varchar,
    @LastName varchar
AS
BEGIN

    SET NOCOUNT ON;

    -- Insert statements for procedure here
    SELECT FirstName  , LastName,Age from UserInfo where FirstName=@FirstName
    and LastName=@FirstName
END
GO

http://www.totaldotnet.com/Article/ShowArticle121_StoreProcBasic.aspx

1
16.11.2011 23:09:05
Какой в ​​этом смысл?
Teoman shipahi 31.07.2015 14:13:37

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

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

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

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

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

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

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

6
8.02.2012 16:35:56

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

2
24.12.2016 09:38:09

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

2
10.03.2012 10:11:39

Все эти ответы, склоняющиеся к LINQ, в основном говорят о ЛЕГКОСТИ РАЗРАБОТКИ, которая более или менее связана с низким качеством кодирования или ленью в кодировании. Я такой только.

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

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

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

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

3
25.09.2012 21:36:30
Загрузка всего в память и фильтрация? Linq может отправлять фильтр как часть запроса в базу данных и возвращает отфильтрованный набор результатов.
liang 10.04.2013 01:41:46
Есть немало людей, которые считают, что LINQ загружает все данные и обрабатывает их с помощью цикла foreach. Это неверно. Он просто компилируется в SQL-запрос и обеспечивает почти одинаковую производительность для большинства операций CRUD. Но да, это не серебряная пуля. Есть случаи, когда использование T-SQL или хранимых процедур может оказаться лучше.
It's a trap 8.03.2017 12:57:35
Я согласен с обоими контраргументами. Однако не совсем верно, что linq отправляет все фильтры в СУБД для работы над ней. Есть несколько вещей, которые работают в памяти, одна из них отличается.
Manish 2.11.2017 20:25:21