LINQ-to-SQL vs procedury składowane? [Zamknięte]

Przyjrzałem się postowi „Przewodnik dla LINQ dla początkujących” na StackOverflow ( Przewodnik dla LINQ dla początkujących ), ale zadałem następujące pytanie:

Za chwilę uruchomimy nowy projekt, w którym prawie wszystkie nasze operacje na bazach danych będą dość prostym odzyskiwaniem danych (istnieje inny segment projektu, który już zapisuje dane). Większość naszych innych projektów do tej pory korzysta z procedur przechowywanych dla takich rzeczy. Chciałbym jednak wykorzystać LINQ-SQL, jeśli ma to większy sens.

Pytanie zatem brzmi: w przypadku prostych operacji pobierania danych, które podejście jest lepsze, LINQ-SQL lub przechowywane procy? Jakieś konkretne plusy lub minusy?

Dzięki.

Niektóre zalety LINQ nad sprocami:

1. Bezpieczeństwo typu : Myślę, że wszyscy to rozumiemy.
2. Abstrakcja : Jest to szczególnie prawdziwe w przypadku LINQ-to-Entities . Ta abstrakcja pozwala również frameworkowi dodawać dodatkowe ulepszenia, z których można łatwo skorzystać. PLINQ jest przykładem dodania obsługi wielowątkowości do LINQ. Zmiany kodu są minimalne, aby dodać tę obsługę. Znacznie trudniej byłoby wykonać ten kod dostępu do danych, który po prostu wywołuje sproki.
3. Obsługa debugowania : mogę debugować zapytania za pomocą dowolnego debugera .NET. Dzięki sprocom nie można łatwo debugować SQL, a to doświadczenie jest w dużej mierze związane z dostawcą bazy danych (MS SQL Server zapewnia analizator zapytań, ale często to nie wystarcza).
4. Niezależnie od dostawcy : LINQ działa z wieloma bazami danych, a liczba obsługiwanych baz danych tylko wzrośnie. Sprocs nie zawsze są przenośne między bazami danych, albo z powodu różnej składni lub obsługi funkcji (jeśli baza danych w ogóle obsługuje sproki).
5. Wdrażanie : inni już o tym wspominali, ale łatwiej jest wdrożyć pojedynczy zestaw niż wdrożyć zestaw sprocków. To również wiąże się z numerem 4.
6. Łatwiej : nie musisz uczyć się T-SQL, aby uzyskać dostęp do danych, ani nie musisz nauczyć się interfejsu API dostępu do danych (np. ADO.NET) niezbędnego do wywoływania sproców. Jest to związane z punktami 3 i 4.

Niektóre wady LINQ vs sproc:

1. Ruch sieciowy : sproki potrzebują tylko serializować dane sproc-name i dane argumentów przez drut, podczas gdy LINQ wysyła całe zapytanie. Może to być bardzo złe, jeśli zapytania są bardzo złożone. Jednak abstrakcja LINQ pozwala Microsoft to poprawić z czasem.
2. Mniej elastyczny : Sprocs może w pełni wykorzystać zestaw funkcji bazy danych. Wsparcie LINQ jest bardziej ogólne. Jest to powszechne w wszelkiego rodzaju abstrakcji języka (np. C # vs asembler).
3. Ponowna kompilacja: jeśli chcesz wprowadzić zmiany w sposobie dostępu do danych, musisz ponownie skompilować, zaktualizować i ponownie wdrożyć zestaw. Sprocs może czasem pozwolić DBA dostroić procedurę dostępu do danych bez potrzeby ponownego wdrażania czegokolwiek.

Bezpieczeństwo i łatwość zarządzania są czymś, o co ludzie się kłócą.

1. Bezpieczeństwo : na przykład możesz chronić swoje wrażliwe dane, ograniczając dostęp do tabel bezpośrednio i umieszczając listy kontroli dostępu w pulach. Jednak dzięki LINQ nadal możesz ograniczyć bezpośredni dostęp do tabel i zamiast tego umieścić listy ACL w aktualizowanych widokach tabel, aby osiągnąć podobny koniec (zakładając, że baza danych obsługuje widoki możliwe do aktualizacji).
2. Zarządzalność : Korzystanie z widoków daje również tę zaletę, że chroni aplikację przed łamaniem schematu (np. Normalizacja tabeli). Możesz zaktualizować widok bez zmiany kodu dostępu do danych.

Kiedyś byłem dużym facetem sproc, ale zaczynam skłaniać się w kierunku LINQ jako ogólnie lepszej alternatywy. Jeśli istnieją obszary, w których sproki są wyraźnie lepsze, prawdopodobnie nadal napiszę sproc, ale uzyskam do niego dostęp za pomocą LINQ. :)

Ogólnie rzecz biorąc jestem zwolennikiem umieszczania wszystkiego w procedurach przechowywanych, z wszystkich powodów, dla których DBA używają od lat. W przypadku Linq prawdą jest, że przy prostych zapytaniach CRUD nie będzie różnicy wydajności.

Podejmując tę ​​decyzję, pamiętaj jednak o kilku rzeczach: użycie dowolnej pary ORM ściśle wiąże się z modelem danych. DBA nie ma wolności wprowadzania zmian w modelu danych bez konieczności zmiany skompilowanego kodu. Za pomocą procedur przechowywanych można ukryć tego rodzaju zmiany do pewnego stopnia, ponieważ lista parametrów i zestawy wyników zwrócone z procedury reprezentują jej umowę, a wewnętrzne elementy mogą być zmieniane, o ile umowa ta jest nadal przestrzegana .

Ponadto, jeśli Linq jest używany do bardziej złożonych zapytań, strojenie bazy danych staje się znacznie trudniejszym zadaniem. Gdy procedura przechowywana działa wolno, DBA może całkowicie skupić się na kodzie w oderwaniu i ma wiele opcji, tak aby kontrakt był nadal spełniony, gdy on / ona jest wykonywany.

Widziałem wiele, wiele przypadków, w których poważne problemy w aplikacji zostały rozwiązane przez zmiany schematu i kodu w procedurach przechowywanych bez żadnych zmian we wdrożonym, skompilowanym kodzie.

Być może podejście hybird byłoby fajne z Linq? Linq można oczywiście wykorzystać do wywoływania procedur przechowywanych.

Linq do Sql.

Serwer Sql buforuje plany zapytań, więc nie ma przyrostu wydajności dla sproców.

Z drugiej strony, twoje instrukcje linq będą logicznie częścią twojej aplikacji i przetestowane. Sprocs są zawsze nieco oddzielone i trudniejsze do utrzymania i testowania.

Gdybym teraz pracował nad nową aplikacją od razu, użyłbym Linq, bez sprocków.

Do podstawowego wyszukiwania danych bez wahania wybrałbym Linq.

Od czasu przejścia do Linq odkryłem następujące zalety:

1. Debugowanie mojego DAL nigdy nie było łatwiejsze.
2. Skompiluj bezpieczeństwo czasowe, gdy twój schemat się zmieni, jest bezcenny.
3. Wdrożenie jest łatwiejsze, ponieważ wszystko jest wkompilowane w biblioteki DLL. Nigdy więcej zarządzania skryptami wdrażania.
4. Ponieważ Linq może obsługiwać zapytania do wszystkiego, co implementuje interfejs IQueryable, będziesz mógł użyć tej samej składni do zapytania XML, Objects i dowolnego innego źródła danych bez konieczności uczenia się nowej składni

LINQ spowoduje wzdęcie pamięci podręcznej procedur

Jeśli aplikacja używa LINQ do SQL, a zapytania wymagają użycia ciągów, które mogą mieć bardzo zmienną długość, pamięć podręczna procedur programu SQL Server zostanie napełniona jedną wersją zapytania dla każdej możliwej długości ciągu. Weźmy na przykład następujące bardzo proste zapytania utworzone na podstawie tabeli Person.AddressTypes w bazie danych 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;

Jeśli oba te zapytania zostaną uruchomione, zobaczymy dwa wpisy w pamięci podręcznej procedur SQL Server: jeden powiązany z NVARCHAR (7), a drugi z NVARCHAR (11). Teraz wyobraź sobie, czy istnieją setki lub tysiące różnych ciągów wejściowych, wszystkie o różnych długościach. Pamięć podręczna procedur zostałaby niepotrzebnie wypełniona różnego rodzaju planami dla tego samego zapytania.

Więcej tutaj: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290

Myślę, że argument pro LINQ wydaje się pochodzić od ludzi, którzy nie mają historii związanej z tworzeniem baz danych (ogólnie).

Zwłaszcza jeśli używasz produktu takiego jak VS DB Pro lub Team Suite, wiele argumentów tutaj przedstawionych nie ma zastosowania, na przykład:

Trudniejsze w utrzymaniu i testowaniu: VS zapewnia pełne sprawdzanie składni, sprawdzanie stylu, sprawdzanie referencji i ograniczeń oraz wiele innych. Zapewnia również pełne możliwości testowania jednostkowego i narzędzia do refaktoryzacji.

LINQ uniemożliwia przeprowadzenie prawdziwych testów jednostkowych, ponieważ (moim zdaniem) nie przejdzie testu ACID.

Debugowanie jest łatwiejsze w LINQ: Dlaczego? VS umożliwia pełne wejście od zarządzanego kodu i regularne debugowanie SP.

Skompilowany w jedną bibliotekę DLL zamiast skryptów wdrażania: Po raz kolejny VS przychodzi na ratunek, gdzie może budować i wdrażać pełne bazy danych lub wprowadzać bezpieczne przyrostowe zmiany danych.

Nie musisz uczyć się TSQL z LINQ: Nie, nie musisz, ale musisz nauczyć się LINQ - jaka jest korzyść?

Naprawdę nie uważam tego za korzyść. Możliwość zmiany czegoś w izolacji może brzmieć dobrze w teorii, ale fakt, że zmiany spełniają kontrakt, nie oznacza, że ​​zwraca prawidłowe wyniki. Aby móc określić, jakie są poprawne wyniki, potrzebny jest kontekst i ten kontekst jest pobierany z kodu wywołującego.

Luźno powiązane aplikacje są ostatecznym celem wszystkich dobrych programistów, ponieważ naprawdę zwiększają elastyczność. Możliwość zmiany rzeczy w izolacji jest fantastyczna, a testy jednostkowe zapewnią, że nadal zwraca odpowiednie wyniki.

Zanim wszyscy zdenerwują się, myślę, że LINQ ma swoje miejsce i wspaniałą przyszłość. Ale w przypadku złożonych aplikacji wymagających dużej ilości danych nie sądzę, aby był gotowy na zastąpienie procedur przechowywanych. Taki pogląd powtórzyłem w tym roku przez MVP na TechEd (pozostaną bezimienne).

EDYCJA: Po stronie procedur przechowywanych LINQ do SQL nadal muszę przeczytać więcej - w zależności od tego, co znajdę, mogę zmienić powyższą diatrybę;)

LINQ jest nowy i ma swoje miejsce. LINQ nie został wymyślony w celu zastąpienia procedury składowanej.

Tutaj skupię się na mitach dotyczących wydajności i CONS, tylko dla „LINQ to SQL”, oczywiście mogę się całkowicie mylić ;-)

(1) Ludzie mówią, że instrukcja LINQ może „buforować” serwer SQL, więc nie traci wydajności. Częściowo prawda. „LINQ to SQL” to w rzeczywistości środowisko wykonawcze tłumaczące składnię LINQ na statystykę TSQL. Zatem z punktu widzenia wydajności instrukcja SQL ADO.NET zakodowana na stałe nie różni się od LINQ.

(2) Podany przykład interfejsu użytkownika obsługi klienta ma funkcję „przeniesienia konta”. ta funkcja sama może zaktualizować 10 tabel DB i zwrócić niektóre wiadomości za jednym razem. Dzięki LINQ musisz zbudować zestaw instrukcji i wysłać je jako jedną partię do serwera SQL. wydajność tej przetłumaczonej partii LINQ-> TSQL nie jest w stanie dopasować procedury składowanej. Powód? ponieważ możesz ulepszyć najmniejszą jednostkę instrukcji w procedurze przechowywanej za pomocą wbudowanego narzędzia do profilowania SQL i planu wykonania, nie możesz tego zrobić w LINQ.

Chodzi o to, że gdy mówimy o pojedynczej tabeli DB i małym zestawie danych CRUD, LINQ jest tak szybki jak SP. Ale dla znacznie bardziej skomplikowanej logiki procedura przechowywana jest bardziej dostrajalna.

(3) „LINQ to SQL” z łatwością sprawia, że ​​nowicjusze wprowadzają świnie wydajności. Każdy starszy facet TSQL może powiedzieć, kiedy nie używać CURSOR (Zasadniczo nie powinieneś używać CURSOR w TSQL w większości przypadków). Dzięki LINQ i uroczej pętli „foreach” z zapytaniem nowicjusz tak łatwo pisze taki kod:

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

Widać, że ten łatwy i porządny kod jest tak atrakcyjny. Ale pod maską środowisko uruchomieniowe .NET wystarczy przetłumaczyć na pakiet aktualizacji. Jeśli jest tylko 500 linii, jest to 500 linii wsad TSQL; Jeśli jest milion linii, to jest hit. Oczywiście doświadczony użytkownik nie użyje tej metody do wykonania tej pracy, ale chodzi o to, że tak łatwo się w nią zakochać.

Najlepszym kodem jest brak kodu, a przy procedurach przechowywanych musisz napisać co najmniej trochę kodu w bazie danych i kod w aplikacji, aby go wywołać, podczas gdy z LINQ do SQL lub LINQ do Entities, nie musisz pisać żadnych dodatkowych kod wykraczający poza jakiekolwiek inne zapytanie LINQ oprócz tworzenia obiektu kontekstu.

LINQ zdecydowanie ma swoje miejsce w bazach danych aplikacji i małych firmach.

Ale w dużym przedsiębiorstwie, w którym centralne bazy danych służą jako centrum wspólnych danych dla wielu aplikacji, potrzebujemy abstrakcji. Musimy centralnie zarządzać bezpieczeństwem i wyświetlać historie dostępu. Musimy być w stanie przeprowadzić analizę wpływu: jeśli wprowadzę niewielką zmianę w modelu danych, aby zaspokoić nową potrzebę biznesową, jakie zapytania należy zmienić i jakie aplikacje należy ponownie przetestować? Widoki i Procedury przechowywane dają mi to. Jeśli LINQ jest w stanie to zrobić i zwiększyć produktywność naszych programistów, z zadowoleniem przyjmuję to - czy ktoś ma doświadczenie w używaniu go w tego rodzaju środowisku?

DBA nie ma wolności wprowadzania zmian w modelu danych bez konieczności zmiany skompilowanego kodu. Za pomocą procedur przechowywanych można ukryć tego rodzaju zmiany do pewnego stopnia, ponieważ lista parametrów i zestawy wyników zwrócone z procedury reprezentują jej umowę, a wewnętrzne elementy mogą być zmieniane, o ile umowa ta jest nadal przestrzegana .

Naprawdę nie uważam tego za korzyść. Możliwość zmiany czegoś w izolacji może brzmieć dobrze w teorii, ale fakt, że zmiany spełniają kontrakt, nie oznacza, że ​​zwraca prawidłowe wyniki. Aby móc określić, jakie są poprawne wyniki, potrzebny jest kontekst i ten kontekst jest pobierany z kodu wywołującego.

IMHO, RAD = LINQ, RUP = Zapisane procesy. Przez wiele lat pracowałem w dużej firmie z listy Fortune 500, na wielu poziomach, w tym w zarządzie, i szczerze mówiąc, nigdy nie zatrudniłem programistów RUP do programowania RAD. Są tak wyciszeni, że bardzo ograniczają wiedzę na temat tego, co robić na innych poziomach procesu. W środowisku wyciszonym sensownie jest dać DBA kontrolę nad danymi poprzez bardzo określone punkty wejścia, ponieważ inni szczerze nie znają najlepszych sposobów zarządzania danymi.

Ale duże firmy poruszają się boleśnie powolnie na arenie programistycznej, co jest niezwykle kosztowne. Są chwile, kiedy musisz poruszać się szybciej, aby zaoszczędzić czas i pieniądze, a LINQ zapewnia to i więcej w pikach.

Czasami myślę, że DBA są stronnicze w stosunku do LINQ, ponieważ uważają, że zagraża to bezpieczeństwu ich pracy. Ale taka jest natura bestii, panie i panowie.

Myślę, że musisz iść z procs na cokolwiek realnego.

Odp.) Zapisywanie całej logiki w linq oznacza, że ​​twoja baza danych jest mniej użyteczna, ponieważ tylko Twoja aplikacja może z niej korzystać.

B) Nie jestem przekonany, że modelowanie obiektów i tak jest lepsze niż modelowanie relacyjne.

C) Testowanie i rozwijanie procedury przechowywanej w SQL jest o wiele szybsze niż cykl edycji kompilacji w dowolnym środowisku Visual Studio. Po prostu edytujesz, F5 i naciskasz select, i startujesz w wyścigach.

D) Łatwiej jest zarządzać i wdrażać procedury przechowywane niż zestawy. Po prostu umieść plik na serwerze i naciśnij F5 ...

E) Linq do sql nadal pisze kiepski kod w czasach, gdy się go nie spodziewasz.

Szczerze mówiąc, myślę, że ostateczną rzeczą byłoby, gdyby stwardnienie rozsiane zwiększyło t-sql, aby mógł wykonać projekcję łączenia w sposób jak to robi Linq. t-sql powinien wiedzieć, czy chcesz na przykład zrobić order.lineitems.part.

LINQ nie zabrania korzystania z procedur przechowywanych. Użyłem trybu mieszanego z LINQ-SQL i LINQ-przechowywaneproc . Osobiście cieszę się, że nie muszę pisać zapisanych procs .... pwet-tu.

Ponadto istnieje problem możliwego wycofania wersji 2.0. Zaufaj mi, że zdarzyło mi się to kilka razy, więc jestem pewien, że stało się to z innymi.

Zgadzam się również, że abstrakcja jest najlepsza. Oprócz tego pierwotnym celem ORM jest dopasowanie RDBMS do koncepcji OO. Jeśli jednak wszystko działało dobrze przed LINQ, ponieważ trzeba było trochę odbiegać od koncepcji OO, to je wkręć. Pojęcia i rzeczywistość nie zawsze pasują do siebie. W IT nie ma miejsca dla wojujących fanatyków.

Zakładam, że masz na myśli Linq To Sql

Dla każdego polecenia CRUD łatwo jest sprofilować wydajność procedury składowanej w stosunku do dowolnej technologii. W takim przypadku każda różnica między nimi będzie nieznaczna. Spróbuj profilować dla obiektu pola 5 (prostych typów) ponad 100 000 wybranych zapytań, aby dowiedzieć się, czy istnieje prawdziwa różnica.

Z drugiej strony prawdziwym przełomem będzie pytanie, czy czujesz się komfortowo, umieszczając logikę biznesową w bazie danych, czy nie, co jest argumentem przeciwko procedurom przechowywanym.

Według guru LINQ definiuję jako motocykl, a SP jako samochód. Jeśli chcesz wybrać się na krótką wycieczkę i mieć tylko małych pasażerów (w tym przypadku 2), skorzystaj z wdzięku dzięki LINQ. Ale jeśli chcesz wybrać się w podróż i mieć duży zespół, myślę, że powinieneś wybrać SP.

Podsumowując, wybór motocykla lub samochodu zależy od trasy (firmy), długości (czasu) i pasażerów (danych).

Mam nadzieję, że to pomaga, mogę się mylić. :RE

Wszystkie te odpowiedzi dotyczące LINQ mówią głównie o ŁATWOŚCI ROZWOJU, która jest mniej lub bardziej związana ze słabą jakością kodowania lub lenistwem w kodowaniu. Jestem taki tylko.

Niektóre zalety lub Linq, czytam tutaj jako łatwe do przetestowania, łatwe do debugowania itp., Ale nie są one połączone z końcowym wyjściem lub użytkownikiem końcowym. To zawsze powoduje kłopoty z wydajnością użytkownika końcowego. Jaki jest sens ładowania wielu rzeczy do pamięci, a następnie stosowania filtrów przy użyciu LINQ?

Ponownie, TypeSafety, ostrzega, że ​​„staramy się unikać niewłaściwego rzutowania czcionek”, które ponownie niskiej jakości próbujemy poprawić, używając linq. Nawet w takim przypadku, jeśli cokolwiek zmieni się w bazie danych, np. Rozmiar kolumny String, to linq musi zostać ponownie skompilowany i bez tego nie byłby bezpieczny w typie. Próbowałem.

Chociaż podczas pracy z LINQ okazało się, że jest dobry, słodki, interesujący itp., Ma on jednak wady ścinania powodujące lenistwo programisty :) i udowodniono 1000 razy, że jest on zły (może być najgorszy) pod względem wydajności w porównaniu do przechowywanych procesorów.

Przestań się lenić. Bardzo się staram. :)

W przypadku prostych operacji CRUD z jednym punktem dostępu do danych powiedziałbym, że skorzystaj z LINQ, jeśli czujesz się komfortowo ze składnią. Dla bardziej skomplikowanej logiki myślę, że sproki są bardziej efektywne pod względem wydajności, jeśli jesteś dobry w T-SQL i jego bardziej zaawansowanych operacjach. Masz również pomoc ze strony Tuning Advisor, SQL Server Profiler, debugowania zapytań z SSMS itp.

Procedura przechowywana ułatwia testowanie i możesz zmienić zapytanie bez dotykania kodu aplikacji. Również w przypadku linq uzyskanie danych nie oznacza, że ​​są to właściwe dane. A testowanie poprawności danych oznacza uruchomienie aplikacji, ale dzięki przechowywanej procedurze testowanie jest łatwe bez dotykania aplikacji.

Wynik można podsumować jako

LinqToSql dla małych witryn i prototypów. To naprawdę oszczędza czas na prototypowanie.

Sps: Universal. Mogę dostroić moje zapytania i zawsze sprawdzać 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

Zarówno LINQ, jak i SQL mają swoje miejsca. Oba mają swoje wady i zalety.

Czasami w przypadku skomplikowanego pobierania danych mogą być potrzebne przechowywane procesy. Czasami możesz chcieć, aby inne osoby korzystały z Twojego przechowywanego proc w Sql Server Management Studio.

Linq to Entities świetnie nadaje się do szybkiego rozwoju CRUD.

Na pewno możesz zbudować aplikację przy użyciu tylko jednego lub drugiego. Lub możesz to pomieszać. Wszystko sprowadza się do twoich wymagań. Ale procy przechowywane w SQL nie znikną w najbliższym czasie.