LINQ-to-SQL vs procedury przechowywane? [zamknięte]

Generalnie jestem zwolennikiem umieszczania wszystkiego w procedurach przechowywanych, ze wszystkich powodów, dla których DBAs od lat się brzęczy. W przypadku Linq, prawdą jest, że nie będzie różnicy w wydajności przy prostych zapytaniach CRUD.

Ale pamiętaj o kilku rzeczach przy podejmowaniu tej decyzji: używając dowolnych par ORM ściśle do swojego modelu danych. DBA nie ma swobody wprowadzania zmian w modelu danych bez zmuszania do zmiany skompilowanego kodu. Dzięki procedurom przechowywanym może ukryć tego rodzaju zmiany w pewnym stopniu, ponieważ lista parametrów i zestaw wyników zwróconych z procedury reprezentują jej kontrakt, a wnętrzności mogą być zmieniane, tak długo, jak długo kontrakt jest nadal spełniony.

A także, jeśli Linq jest używany do bardziej złożonych zapytań, dostrajanie bazy danych staje się znacznie trudniejszym zadaniem. Gdy procedura składowana działa wolno, DBA może całkowicie skupić się na kodzie w izolacji i ma wiele opcji, tylko tak, że umowa jest nadal usatysfakcjonowany, gdy skończy.

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

Może podejście hybrydowe byłoby miłe z Linq? Linq może być oczywiście używany do wywoływania procedur składowanych.

Linq do Sql.

Sql server będzie buforować plany zapytań, więc nie ma zwiększenia wydajności dla sprocks.

Twoje wypowiedzi linq, z drugiej strony, będą logicznie częścią i przetestowane z Twoją aplikacją. Zębatki są zawsze nieco oddzielone i trudniejsze w utrzymaniu i testowaniu.

Gdybym teraz pracował nad nową aplikacją od zera, użyłbym tylko Linq, bez sprocks.

Dla podstawowego pobierania danych bez wahania wybrałbym Linq.

Od przejścia na Linq znalazłem następujące zalety:

Debugowanie mojego DAL nigdy nie było łatwiejsze.
1. Bezpieczeństwo kompilacji, gdy zmienia się schemat jest bezcenne.
2. wdrażanie jest łatwiejsze, ponieważ wszystko jest kompilowane do bibliotek DLL. koniec z zarządzaniem skryptami wdrażania.
3. ponieważ Linq może obsługiwać wszystko, co implementuje interfejs IQueryable, będziesz w stanie używaj tej samej składni do odpytywania XML, obiektów i innych źródeł danych bez konieczności uczenia się nowej składni

LINQ wykona Cache procedury

Jeśli aplikacja używa LINQ do SQL, a zapytania wymagają użycia łańcuchów, które mogą mieć bardzo zmienną długość, pamięć podręczna procedury SQL Server zostanie przepełniona jedną wersją zapytania dla każdej możliwej długości łańcucha. Na przykład rozważ następujące bardzo proste zapytania utworzone przeciwko osobie.Tabela adresów 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 procedury SQL Server: jeden związany z NVARCHAR( 7), a drugi z nvarchar(11). Teraz wyobraź sobie, że istnieją setki lub tysiące różnych ciągów wejściowych, Wszystkie o różnych długościach. Bufor procedury zostałby niepotrzebnie wypełniony różnego rodzaju różnymi planami dla dokładnie 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 z rozwojem baz danych (w ogóle).

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

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

LINQ makes true testowanie jednostkowe niemożliwe, ponieważ (moim zdaniem) nie sprawdza się w kwasie.

Debugowanie jest łatwiejsze w LINQ: Dlaczego? VS pozwala na pełne wprowadzenie kodu zarządzanego i regularne debugowanie SPs.

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

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

Naprawdę nie postrzegam tego jako korzyści. Możliwość zmiany czegoś w izolacji może brzmieć dobrze w teorii, ale tylko dlatego, że zmiany spełniają kontrakt nie oznacza, że zwraca prawidłowe wyniki. Aby móc określić, jakie są poprawne wyniki, potrzebujesz kontekstu i uzyskasz ten kontekst z kodu wywołującego.

Um, luźno powiązane aplikacje są ostatecznym celem wszystkich dobrych programistów, ponieważ naprawdę zwiększają elastyczność. Możliwość zmiany rzeczy w izolacja jest fantastyczna i to twoje testy jednostkowe zapewnią, że nadal zwracają odpowiednie wyniki.

Zanim wszyscy się zdenerwujecie, myślę, że LINQ ma swoje miejsce i ma wspaniałą przyszłość. Ale w przypadku złożonych, wymagających dużej ilości danych aplikacji nie sądzę, aby była gotowa do zastąpienia procedur składowanych. To był pogląd, który powtórzył MVP w TechEd w tym roku (pozostaną bezimienni).

EDIT: po stronie procedury składowanej LINQ do SQL jest coś, co nadal muszę przeczytać więcej na-w zależności od tego co znajdę mogę zmienić moją powyższą diatrybę;)

LINQ jest nowy i ma swoje miejsce. LINQ nie jest wymyślony, aby zastąpić procedurę składowaną.

Tutaj skupię się na niektórych mitów wydajności i minusach, tylko dla "LINQ do SQL", oczywiście mogę się całkowicie mylić; -)

(1)ludzie mówią, że statment LINQ może "buforować" w SQL server, więc nie traci wydajności. Częściowo prawda. "LINQ to SQL" jest w rzeczywistości runtime tłumaczącym składnię LINQ na statment TSQL. Więc z punktu widzenia wydajności,ciężko zakodowany ADO.NET instrukcja SQL nie ma różnicy niż LINQ.

(2)podany przykład, interfejs obsługi klienta ma funkcję "przelew konta". ta funkcja sama w sobie może zaktualizować tabele 10 DB i zwrócić niektóre wiadomości w jednym ujęciu. W LINQ musisz zbudować zestaw instrukcji i wysłać je jako jedną partię do SQL server. wydajność tej przetłumaczonej partii LINQ - > TSQL nie może się równać z procedurą składowaną. Powód? ponieważ możesz dostosować najmniejszą jednostkę instrukcji w procedurze przechowywanej za pomocą wbudowanego SQL profilera i wykonania plan tool, 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. Jednak w przypadku znacznie bardziej skomplikowanej logiki, procedura składowana jest bardziej wydajna.

(3) "LINQ to SQL" łatwo sprawia, że nowicjusze wprowadzają świnie wydajności. Każdy starszy facet z TSQL może Ci powiedzieć, kiedy nie używać kursora (zasadniczo nie powinieneś używać kursora w TSQL w większości przypadków). Z LINQ i uroczą pętlą "foreach" z query, tak łatwo jest nowicjusz do napisania takiego kodu:

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

Widać, że ten prosty, porządny kod jest tak atrakcyjny. Ale pod maską,. NET runtime po prostu przetłumaczyć to do partii aktualizacji. Jeśli jest tylko 500 linii, jest to 500 linii TSQL batch; jeśli jest milion linii, jest to hit. Oczywiście doświadczony użytkownik nie użyje tego sposobu do wykonania tej pracy, ale chodzi o to, że tak łatwo wpaść w ten sposób.

Najlepszym kodem jest brak kodu, a w przypadku procedur przechowywanych musisz napisać przynajmniej część kodu w bazie danych i kodu w aplikacji , aby go wywołać, podczas gdy w przypadku LINQ to SQL lub LINQ to encji, nie musisz pisać żadnego dodatkowego kodu poza jakimkolwiek innym zapytaniem LINQ, poza tworzeniem instancji obiektu kontekstowego.

LINQ zdecydowanie ma swoje miejsce w bazach danych specyficznych dla aplikacji oraz w małych firmach.

Ale w dużym przedsiębiorstwie, gdzie Centralne bazy danych służą jako centrum wspólnych danych dla wielu aplikacji, potrzebujemy abstrakcji. Musimy centralnie zarządzać bezpieczeństwem i pokazywać historie dostępu. Musimy być w stanie przeprowadzić analizę wpływu: jeśli wprowadzę niewielką zmianę w modelu danych, aby zaspokoić nowe potrzeby biznesowe, jakie zapytania należy zmienić i jakie aplikacje należy ponownie przetestować? Widoki i Procedury magazynowe mi to dają. Jeśli LINQ potrafi to wszystko zrobić, a nasi programiści będą bardziej produktywni, to z przyjemnością. czy ktoś ma doświadczenie w używaniu go w tego typu środowisku?

DBA nie ma wolności wprowadzania zmian do modelu danych bez wymuszania aby zmienić skompilowany kod. Z procedur przechowywanych, można je ukryć rodzaju zmian do pewnego stopnia, ponieważ Lista parametrów i zestaw wyników) zwrócone z procedury reprezentują jego kontrakt, a wnętrzności mogą być zmienił się, tylko tak długo, jak to umowa jest nadal spełniona.

IMHO, RAD = LINQ, RUP = przechowywane Procs. Przez wiele lat pracowałem dla dużej firmy z listy Fortune 500, na wielu poziomach, w tym w zarządzaniu, i szczerze mówiąc, nigdy nie zatrudniłbym programistów RUP do tworzenia RAD development. Są na tyle silni, że mają bardzo ograniczoną wiedzę o tym, co robić na innych poziomach procesu. W środowisku silosowym sensowne jest zapewnienie DBAs kontroli nad danymi za pośrednictwem bardzo specyficznych punktów wejścia, ponieważ inni szczerze mówiąc nie znają najlepszych sposobów na uzyskanie danych zarządzanie.

Ale duże przedsiębiorstwa poruszają się boleśnie powoli na arenie rozwoju, a to jest niezwykle kosztowne. Są chwile, kiedy trzeba działać szybciej, aby zaoszczędzić czas i pieniądze, a LINQ zapewnia to i więcej w pikach.

Czasami myślę, że DBAs są stronnicze wobec LINQ, ponieważ czują, że zagraża to ich bezpieczeństwu pracy. Ale taka jest natura bestii, panie i panowie.

Myślę, że trzeba iść z procs do czegokolwiek prawdziwego.

A) zapisanie całej logiki w linq oznacza, że Twoja baza danych jest mniej użyteczna, ponieważ tylko Twoja aplikacja może ją wykorzystać.

B) nie jestem przekonany, czy modelowanie obiektowe jest lepsze od modelowania relacyjnego.

C) Testowanie i rozwijanie procedury składowanej w SQL jest o wiele szybsze niż cykl edycji kompilacji w dowolnym środowisku Visual Studio. Wystarczy edytować, F5 i nacisnąć wybierz i jesteś off do rasy.

D) łatwiej jest zarządzać i wdrażać procedury składowane niż zespoły.. wystarczy umieścić plik na serwerze i nacisnąć F5...

E) Linq do sql wciąż pisze gówniany kod, kiedy się go nie spodziewasz.

Szczerze mówiąc, myślę, że najlepszą rzeczą byłoby, aby MS rozszerzył t-sql tak, aby mógł on implikalnie wykonać projekcję join tak, jak robi to linq. t-sql powinien wiedzieć, czy chcesz zrobić porządek.lineitems.część, na przykład.

LINQ nie zabrania stosowania procedur przechowywanych. Używałem trybu mieszanego z LINQ-SQL i LINQ-storedproc. Osobiście cieszę się, że nie muszę pisać zapisanych proc....pwet-tu.

Jest też problem z ewentualnym wycofaniem wersji 2.0. Zaufaj mi, zdarzyło mi się to kilka razy, więc jestem pewien, że zdarzyło się to innym.

Zgadzam się również, że abstrakcja jest najlepsza. Wraz z faktem, że pierwotnym celem każdego ORM jest sprawienie, aby RDBMS ładnie pasował do koncepcji OO. Jeśli jednak wszystko działało dobrze przed LINQ przez to, że musiałem trochę odbiegać od koncepcji OO, to wkręć je. Koncepcje i rzeczywistość nie zawsze pasują do siebie. Nie ma miejsca dla wojowniczych fanatyków w nim.

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

Dla każdego polecenia CRUD łatwo jest profilować wydajność procedury składowanej w porównaniu z dowolną technologią. W takim przypadku różnica między nimi będzie znikoma. Spróbuj profilować obiekt pola 5 (typy proste) ponad 100 000 zapytań select, aby dowiedzieć się, czy istnieje prawdziwa różnica.

Z drugiej strony prawdziwym deal-breaker będzie pytanie, Czy czujesz się komfortowo umieszczając swoją logikę biznesową w bazie danych, czy nie, które jest argumentem przeciwko procedurom składowanym.

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), idź z wdziękiem z LINQ. Ale jeśli chcesz wybrać się w podróż i mieć duży zespół, myślę, że powinieneś wybrać SP.

Podsumowując, wybór pomiędzy motocyklem a samochodem zależy od trasy (działalności), długości (czasu) i pasażerów (danych).

Mam nadzieję, że to pomoże, mogę się mylić. : D

Wszystkie te odpowiedzi skłaniające się ku 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. Tylko taki jestem.

Niektóre zalety lub Linq, czytam tutaj jako, łatwe do przetestowania, łatwe do debugowania itp, ale nie są one podłączone do końcowego wyjścia lub użytkownika końcowego. To zawsze będzie powodować problemy użytkownika końcowego na wydajność. Co punkt ładowanie wielu rzeczy w pamięci, a następnie stosowanie filtrów w użyciu LINQ?

Ponownie TypeSafety, jest ostrożność, że "jesteśmy ostrożni, aby uniknąć niewłaściwego typecastingu", który ponownie słaba jakość staramy się poprawić za pomocą linq. Nawet w takim przypadku, jeśli coś w bazie danych ulegnie zmianie, np. rozmiar kolumny String, to linq musi zostać ponownie skompilowane i bez tego nie będzie typesafe .. Próbowałem.

Chociaż okazało się, że jest dobry, słodki, interesujący itp podczas pracy z LINQ, ma wadę, że programista jest leniwy:) i udowodniono to 1000 razy że jest zły (może być najgorszy) pod względem wydajności w porównaniu do przechowywanych proc.

Przestań być leniwy. Bardzo się staram. :)

Stored Procs vs Code (poprzednia dyskusja)

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

Procedura składowana ułatwia testowanie i można zmienić zapytanie bez dotykania kodu aplikacji. Również w przypadku linq uzyskanie danych nie oznacza, że są one odpowiednie. Testowanie poprawności danych oznacza uruchomienie aplikacji, ale z procedurą składowaną można ją łatwo przetestować bez dotykania aplikacji.

Wynik można podsumować jako

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

Sps : Uniwersalny. Mogę dostroić moje zapytania i zawsze sprawdzić 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 do skomplikowanego pobierania danych może być potrzebny zapisany proc. Czasami możesz chcieć, aby inne osoby używały twojego zapisanego proc w Sql Server Management Studio.

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

Oczywiście, że możesz zbudować aplikację używając tylko jednej lub drugiej. Albo możesz to pomieszać. Wszystko sprowadza się do Twoich wymagań. Ale SQL przechowywane procs nie odejdzie żadnych wkrótce.