LINQ до SQL проти збережених процедур? [зачинено]

Я подивився публікацію "Посібника для початківців LINQ" тут на StackOverflow ( Посібник для початківців по LINQ ), але у мене виникло додаткове запитання:

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

Отже, питання такий: для простих пошуків даних, який підхід краще, LINQ до SQL або збережених програм? Будь-які конкретні профі чи противники?

Дякую.

Деякі переваги LINQ перед зірочками:

1. Тип безпеки : Я думаю, що ми всі це розуміємо.
2. Абстракція : Особливо це стосується LINQ до сутностей . Ця абстракція також дозволяє рамці додавати додаткові вдосконалення, якими ви можете легко скористатися. PLINQ - приклад додавання підтримки LINQ для багатопотокових передач. Зміни коду мінімальні, щоб додати цю підтримку. БУДЬ важче зробити цей код доступу до даних, який просто викликає паростки.
3. Підтримка налагодження : я можу використовувати будь-який налагоджувач .NET для налагодження запитів. За допомогою паростків ви не можете легко налагодити SQL, і цей досвід значною мірою пов'язаний з постачальником вашої бази даних (MS SQL Server надає аналізатор запитів, але часто цього недостатньо).
4. Агностика постачальників : LINQ працює з великою кількістю баз даних, а кількість підтримуваних баз даних лише збільшуватиметься. Sprocs не завжди переносяться між базами даних, або через різний синтаксис або підтримку функцій (якщо база даних взагалі підтримує відростки).
5. Розгортання : інші вже згадували про це, але простіше розгорнути одну збірку, ніж розгорнути набір відростків. Це також пов'язане з №4.
6. Простіше : Вам не доведеться вивчати T-SQL для доступу до даних, а також не потрібно вивчати API доступу до даних (наприклад, ADO.NET), необхідний для виклику паростків. Це пов’язано з №3 та №4.

Деякі недоліки LINQ vs паростків:

1. Мережевий трафік : відросткам потрібно лише серіалізувати дані про ім'я парока та аргументи по дроту, в той час як LINQ надсилає весь запит. Це може стати дуже поганим, якщо запити дуже складні. Однак абстракція LINQ дозволяє Microsoft з часом покращити це.
2. Менш гнучкі : Sprocs можуть повністю скористатися набором функцій бази даних. LINQ, як правило, є більш загальним у своїй підтримці. Це є загальним для будь-якої мови абстракції (наприклад, C # vs асемблер).
3. Перекомпіляція : Якщо вам потрібно внести зміни в спосіб доступу до даних, вам потрібно перекомпілювати, виконати версію та повторно застосувати свою збірку. Sprocs іноді можуть дозволити DBA налаштовувати порядок доступу до даних без необхідності повторно використовувати їх .

Безпека та керованість - це те, про що люди також сперечаються.

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

Раніше я був великим хлопцем, але я взагалі починаю схилятися до LINQ як кращої альтернативи. Якщо є деякі області, де зірочки явно кращі, я, мабуть, все-таки напишу проросток, але отримаю доступ до нього за допомогою LINQ. :)

Я, як правило, прихильник вкладати все в збережені процедури, з усіх причин, які DBA намагаються роками. У випадку з Linq це правда, що не буде різниці в продуктивності з простими CRUD-запитами.

Але майте на увазі кілька речей, приймаючи таке рішення: використовуючи будь-які пари ORM, ви чітко до вашої моделі даних. DBA не має свободи вносити зміни в модель даних, не змушуючи вас змінювати складений код. За допомогою збережених процедур ви можете приховати подібні зміни до певної міри, оскільки список параметрів та набір результатів, повернутих із процедури, є його контрактом, а внутрішні можуть бути змінені навколо, доки цей договір все ще виконується .

А також, якщо Linq використовується для більш складних запитів, налаштування бази даних стає набагато складнішим завданням. Коли збережена процедура працює повільно, DBA може повністю зосередитись на коді ізольовано і має безліч варіантів, тільки щоб цей контракт все ще виконувався, коли він / вона буде виконаний.

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

Можливо, підхід гібриду був би непоганий з Linq? Звичайно, Linq можна використовувати для виклику збережених процедур.

Linq - Sql.

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

З іншого боку, ваші твердження linq будуть логічно включені та перевірені у вашій заявці. Спроки завжди трохи відокремлені і їх складніше підтримувати та перевіряти.

Якби я працював над новою програмою з нуля зараз, я б просто застосував Linq, без відростків.

Щодо пошуку основних даних, я б без вагань збирався Linq.

Після переїзду до Linq я виявив такі переваги:

1. Налагодження мого DAL ніколи не було простішим.
2. Компілюйте безпеку часу, коли зміна вашої схеми безцінна.
3. Розгортання простіше, оскільки все складено в DLL. Більше управління сценаріями розгортання більше немає.
4. Оскільки Linq може підтримувати запити будь-чого, що реалізує інтерфейс IQueryable, ви зможете використовувати той самий синтаксис для запиту XML, об’єктів та будь-якого іншого джерела даних без необхідності вивчати новий синтаксис

LINQ роздує кеш процедури

Якщо програма використовує LINQ для 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

Я думаю, що аргумент про LINQ, здається, походить від людей, які не мають історії з розробкою баз даних (загалом).

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

Важче у обслуговуванні та тестуванні: VS забезпечує повну перевірку синтаксису, перевірку стилів, перевірку референсів та обмежень тощо. Він також забезпечує повну можливість тестування одиниць та інструменти рефакторингу.

LINQ унеможливлює тестування справжніх одиниць, оскільки (на мій погляд) це не відповідає тесту на кислоту.

Налагодження простіше в LINQ: Чому? VS дозволяє здійснювати повне вхід з керованого коду та регулярну налагодження SP.

Скомпільований в єдину DLL, а не в сценарії розгортання. Ще раз VS приходить на допомогу, де він може створювати та розгортати повні бази даних або робити додаткові зміни, безпечні для даних.

Не потрібно вивчати TSQL за допомогою LINQ: Ні, ви цього не робите, але ви повинні вивчити LINQ - де користь?

Я справді не вважаю це користю. Бути в змозі щось змінити ізольовано, теоретично може звучати добре, але тільки тому, що зміни виконують контракт, не означає, що це поверне правильні результати. Щоб мати можливість визначити, які правильні результати, вам потрібен контекст, і ви отримаєте цей контекст з коду виклику.

Гм, слабко поєднані програми - це кінцева мета всіх хороших програмістів, оскільки вони дійсно збільшують гнучкість. Можливість змінити речі поодинці - це фантастично, і саме ваші одиничні тести забезпечать, що вона все одно повертає відповідні результати.

Перш ніж все засмутитися, я думаю, що LINQ має своє місце і має грандіозне майбутнє. Але для складних додатків, що вимагають великих даних, я не думаю, що вони готові зайняти місце збережених процедур. Цю думку я одержав відгук MVP в TechEd цього року (вони залишаться безіменними).

EDIT: Сторінка речей, що зберігаються у процедурі LINQ to SQL, - це те, про що я все-таки потрібно прочитати докладніше - залежно від того, що я можу змінити вищевказаний діатріб;)

LINQ є новим і має своє місце. LINQ не придуманий для заміни збереженої процедури.

Тут я зупинюсь на деяких міфах щодо продуктивності та CONS, лише для "LINQ до SQL", я, звичайно, можу бути абсолютно невірним ;-)

(1) Люди кажуть, що LINQ-повідомлення може «кешувати» на SQL-сервері, тому він не втрачає продуктивності. Частково правда. "LINQ в 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 виконання просто переводить це в пакет оновлення. Якщо всього 500 рядків, це пакетна лінія TSQL 500 рядків; Якщо є мільйон рядків, це хіт. Звичайно, досвідчений користувач не використовуватиме цей спосіб для виконання цієї роботи, але справа в тому, що так легко падати таким чином.

Найкращий код - це не код, і для збережених процедур вам потрібно написати хоча б якийсь код у базі даних та код у програмі, щоб викликати його, тоді як для LINQ до SQL або LINQ для сутностей вам не потрібно писати додаткових код за межами будь-якого іншого запиту LINQ окрім інстанції контекстного об'єкта.

LINQ, безумовно, має місце в базі даних, що стосуються додатків, і в малому бізнесі.

Але на великому підприємстві, де центральні бази даних служать вузлом загальних даних для багатьох додатків, нам потрібна абстракція. Нам потрібно централізовано керувати безпекою та показувати історії доступу. Нам потрібно вміти робити аналіз впливу: якщо я вніс невелику зміну в модель даних, щоб забезпечити нову потребу в бізнесі, які запити потрібно змінити та які додатки потрібно повторно перевірити? Перегляди та збережені процедури дають мені це. Якщо LINQ може все це зробити і зробити наших програмістів більш продуктивними, я вітаю - хтось має досвід використання цього в такому середовищі?

DBA не має свободи вносити зміни в модель даних, не змушуючи вас змінювати складений код. За допомогою збережених процедур ви можете приховати подібні зміни до певної міри, оскільки список параметрів та набір результатів, повернутих із процедури, є його контрактом, а внутрішні можуть бути змінені навколо, доки цей договір все ще виконується .

Я справді не вважаю це користю. Бути в змозі щось змінити ізольовано, теоретично може звучати добре, але тільки тому, що зміни виконують контракт, не означає, що це поверне правильні результати. Щоб мати можливість визначити, які правильні результати, вам потрібен контекст, і ви отримаєте цей контекст з коду виклику.

IMHO, RAD = LINQ, RUP = Збережені програми. Я працював у великій компанії Fortune 500 протягом багатьох років, на багатьох рівнях, включаючи управління, і, чесно кажучи, я ніколи не наймав розробників RUP для розробки RAD. Вони настільки осімі, що вони дуже обмежені знання, що робити на інших рівнях процесу. У оточеному середовищі має сенс надати DBA контролю над даними через дуже конкретні точки введення, оскільки інші, чесно кажучи, не знають кращих способів управління даними.

Але великі підприємства болісно повільно рухаються на арені розвитку, і це надзвичайно дорого. Бувають випадки, коли вам потрібно рухатись швидше, щоб заощадити і час, і гроші, і LINQ надає це і багато іншого в лопатах.

Іноді я думаю, що DBA є упередженими щодо LINQ, оскільки вони вважають, що це загрожує безпеці їх роботи. Але така природа звіра, пані та панове.

Я думаю, вам потрібно розібратися з документами для будь-чого реального.

A) Введення всієї вашої логіки у linq означає, що ваша база даних є менш корисною, оскільки лише ваша програма може споживати її.

Б) Я не переконаний, що моделювання об'єктів все-таки краще, ніж реляційне моделювання.

C) Тестування та розробка збереженої процедури в SQL - це пекло набагато швидше, ніж цикл редагування компіляції в будь-якому середовищі Visual Studio. Ви просто редагуєте, F5 і натискаєте селектор, і ви їдете на гонки.

D) Простіше керувати та розгортати збережені процедури, ніж збірки. Ви просто помістите файл на сервер і натисніть F5 ...

E) Linq to sql як і раніше записує шалений код у ті часи, коли ви цього не очікуєте.

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

LINQ не забороняє використовувати збережені процедури. Я використовував змішаний режим з LINQ-SQL і LINQ-зберігаєтьсяproc . Особисто я радий, що мені не потрібно писати збережені документи .... pwet-tu.

Також є питання про можливий відкат 2.0. Повірте мені, це траплялося зі мною пару разів, тому я впевнений, що це трапилося і з іншими.

Я також згоден, що абстракція найкраща. Поряд з фактом, первісна мета ОРМ - змусити RDBMS добре узгоджуватися з концепціями ОО. Однак, якщо до LINQ все працювало нормально, потрібно трохи відхилитися від понять OO, тоді викрутіть їх. Поняття та реальність не завжди добре поєднуються. В ІТ немає місця для войовничих завзятих.

Я припускаю, що ви маєте на увазі Linq To Sql

Для будь-якої команди CRUD легко профілювати продуктивність збереженої процедури проти будь-якої технології. У цьому випадку будь-яка різниця між ними буде незначною. Спробуйте профілювати для 5 (простих типів) польовий об'єкт понад 100 000 обраних запитів, щоб з’ясувати, чи є реальна різниця.

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

За словами гуру, я визначаю LINQ як мотоцикл, а SP як автомобіль. Якщо ви хочете поїхати в коротку поїздку і мати лише маленьких пасажирів (у цьому випадку 2), виїжджайте вишукано з LINQ. Але якщо ви хочете відправитися в подорож і мати велику групу, я думаю, вам слід вибрати SP.

Як висновок, вибір між мотоциклом чи автомобілем залежить від вашого маршруту (бізнесу), довжини (часу) та пасажирів (даних).

Сподіваюся, це допоможе, я можу помилятися. : D

Усі ці відповіді, схиляючись до LINQ, в основному говорять про ПРОСТО РОЗВИТКУ, яке більш-менш пов'язане з поганою якістю кодування або ліністю кодування. Я лише такий.

Деякі переваги або Linq, я читаю тут як, легко перевірити, легко налагоджувати і т. Д., Але вони відсутні там, де підключено до Кінцевого виводу або кінцевого користувача. Це завжди спричиняє проблеми кінцевому користувачеві щодо продуктивності. Який сенс завантажувати багато речей у пам'ять, а потім застосовувати фільтри, використовуючи LINQ?

Знову ж таки, TypeSafety - це застереження, що "ми обережні, щоб уникнути неправильної клавіатури", що знову низької якості ми намагаємося покращити, використовуючи linq. Навіть у такому випадку, якщо щось у базі даних зміниться, наприклад розмір стовпця String, тоді linq потрібно перекомпілювати і не буде без цього безпечним.

Хоча, ми виявили, що це добре, мило, цікаво тощо під час роботи з LINQ, це має недолік, коли робить розробника ледачим :), і в 1000 разів доведено, що це погано (можливо, найгірше) по продуктивності порівняно зі збереженими програмами.

Перестаньте лінуватися. Я дуже стараюся. :)

Для простих операцій CRUD з єдиною точкою доступу до даних я б сказав, що перейдіть на LINQ, якщо вам зручно з синтаксисом. Що стосується більш складної логіки, я думаю, що відростки є більш ефективними, якщо ви добре володієте T-SQL та його більш досконалими операціями. Вам також надається допомога з налаштування консультанта, SQL Server Profiler, налагодження запитів із SSMS тощо.

Збережена процедура полегшує тестування, і ви можете змінити запит, не торкаючись коду програми. Також із linq отримання даних не означає його правильних даних. І перевірити правильність даних означає запустити програму, але зі збереженою процедурою її легко перевірити, не торкаючись програми.

Результат можна підсумувати як

LinqToSql для невеликих сайтів та прототипів. Це дійсно економить час для прототипування.

Sps: Універсальний. Я можу точно налаштувати свої запити і завжди перевіряти ActualExecutionPlan / EstimatedExecutionPlan.

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

І LINQ, і SQL мають свої місця. У обох є свої недоліки та переваги.

Іноді для складного пошуку даних вам можуть знадобитися збережені документи. І іноді ви можете захотіти, щоб інші користувачі використовували вашу збережену програму в Sql Server Management Studio.

Linq to Entities чудово підходить для швидкого розвитку CRUD.

Звичайно, ви можете створити додаток, використовуючи лише одне чи інше. Або ви можете змішати його. Все зводиться до ваших вимог. Але програми, що зберігаються в SQL, незабаром не зникнуть.