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

188

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.

Scott Marlowe
źródło

Odpowiedzi:

192

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. :)

Chris Gillum
źródło
33
„LINQ działa z wieloma bazami danych”, ale LINQTOSQL obsługuje tylko SQL Server.
RussellH
7
LINQ to Entities współpracuje z Postgres i MySql oprócz MSSQL. Nie jestem pewien, ale pomyślałem, że przeczytałem, że jest coś dla Oracle.
bbqchickenrobot
devart dotConnect ma w sobie coś z Oracle, ale jest cholernie cholerny. Nie mogę też przezwyciężyć deficytu wydajności, który jest spowodowany przez wybranie danych z bazy danych w celu ich aktualizacji (Attach () jest również możliwe, ale jest raczej kiepskie)
Ed James
5
Nie widziałem tu nikogo, kto wspominałby o ponownym użyciu kodu. Nie możesz ponownie użyć linq w aplikacji VB6, asp lub Maker plików pro. Jeśli umieścisz coś w bazie danych, będzie można go ponownie użyć WSZĘDZIE. Można zrobić dll z linq w nim, ale wydaje się, że robi się to zbyt skomplikowane i gówniane imo. Dodanie funkcji lub przechowywanego proc, które można ponownie wykorzystać, jest znacznie prostsze.
MikeKulls
Mówiąc o ponownym użyciu kodu w TSQL (1) powodzenia w próbie zapisania wyników procedury przechowywanej w tabeli tymczasowej bez uciekania się do dynamicznego SQL. (2) Niewiele możesz zrobić, aby zorganizować wszystkie swoje procesy / funkcje; przestrzeń nazw szybko się zaśmieca. (3) Napisałeś potężną instrukcję select, ale teraz chcesz, aby użytkownik mógł wybrać kolumnę, która zostanie posortowana - w TSQL może być konieczne użycie CTE, który wykonuje numer_wiersza nad każdą kolumną, którą można posortować; w LINQ można to rozwiązać kilkoma ifstwierdzeniami po namyśle.
sparebytes,
77

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.

Eric Z Beard
źródło
9
Jedną z zaniedbanych funkcji jest bezpieczeństwo. Dzięki Linq musisz udostępniać tabele bezpośrednio aplikacji. Dzięki procedurom przechowywanym możesz ograniczyć dostęp do tych procedur i egzekwować wymagania biznesowe.
NotMe
19
„DBA nie ma wolności wprowadzania zmian w modelu danych bez konieczności zmiany skompilowanego kodu”. Dlaczego miałbyś to popierać? Nikt nie powinien mieć „swobody” wprowadzania zmian, to jest punkt zarządzania konfiguracją. Niezależnie od tego zmiany powinny przejść przez programowanie, testowanie itp. Przed wdrożeniem.
Neil Barnwell
6
@Neil: Tak, ale nie może dokonywać zmian w środowisku programistycznym bez zmuszania programisty do zmiany kodu.
Adam Robinson
37
Muszę powiedzieć, że wiele razy widziałem argument dotyczący ścisłego łączenia się z bazami danych i nie jestem pewien, czy jest on tak ważny. Nigdy nie spotkałem się z sytuacją (poza trywialnymi przykładami), w której chcę zmienić bazę danych, która i tak nie wymaga zmiany kodu wyżej. I tak naprawdę, w jaki sposób Linq różni się od przechowywanych procesów lub sparametryzowanych zapytań. Warstwa dostępu do danych powinna być nadal dobrze oddzielona i wyodrębniona, niezależnie od tego, czy używasz ORM, czy czegoś prostszego. To daje luźne połączenie, a nie jaką technologię używasz. Just my 2c
Simon P Stevens,
7
Widziałem 199 procedur składowanych napisanych niepotrzebnie dla każdej 1 zmiany schematu, która była chroniona przed aplikacjami za pomocą podpisu SP, ale podobnie jak powiedział Simon P Stevens, zmiany semantyczne w użyciu SP wymagały zmian aplikacji 100% i tak czas. Nie wspominając już o tym, że samo istnienie SP powoduje, że jakiś przyszły deweloper lub dba wciela logikę biznesową w SP. Potem jeszcze trochę i jeszcze więcej.
64

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.

Keith
źródło
8
Nie zgadzam się co do twoich komentarzy na temat braku korzyści dla sproców. Wyprofilowałem serię podejść do dostępu do SQL Servera w systemie prod, a użycie Prepare + przechowywane procy miało jedne z najlepszych rezultatów. Nawet w wielu połączeniach o tej samej logice. Być może jednak masz rację w przypadku DB z niskim zużyciem.
torial
Jeśli jesteś i będziesz najzdolniejszym programistą zapytań do baz danych, skorzystaj z tego, co znasz. W przeciwieństwie do kodeksu postępowania nie można powiedzieć „jeśli daje prawidłową odpowiedź, wyślij ją”.
dkretz
5
@ RussellH: Tak było w przypadku .Net 3.5, naprawiono to w .Net 4 (zarówno dla L2S, jak i
L2E
3
@Kieth Nie przypadek! Z Linq powstaje o wiele więcej planów wykonania niż SP. Istnieją korzyści z kodem do debugowania; ale problemy z rekompilacją w cyklu wdrażania firmy; brak elastyczności w testowaniu różnych zapytań ACTION, GDZIE, ZAMÓWIĆ. Zmiana kolejności instrukcji WHERE może spowodować przetworzenie innego zapytania; pobieranie wstępne; nie można tego łatwo zrobić w Linq. Musisz mieć dostępną warstwę danych do ulepszenia. SP są trudniejsze w utrzymaniu i testowaniu? Jeśli nie jesteś do tego przyzwyczajony; ale SP są korzystne dla korpusów i VLDB, wysokiej dostępności itp.! Linq jest przeznaczony do małych projektów, do samodzielnej pracy; idź po to.
SnapJag
4
@ SnapJag - Masz rację, że sproki dają ci większą kontrolę nad ziarnem, ale faktem jest, że 99% czasu (nawet w dużych systemach korporacyjnych, w których pracuję) nie potrzebujesz żadnej dodatkowej optymalizacji. Sproc są trudniejsze w utrzymaniu i sprawdzeniu, czy jesteś do nich przyzwyczajony, czy nie - jestem do nich bardzo przyzwyczajony (wcześniej byłem programistą) i upewniam się, że sproc dla każdej operacji CRUD dla różnych tabel jest aktualne to ból. Najlepszą praktyką (IMHO) jest kodowanie w najłatwiejszy sposób, a następnie przeprowadzanie kontroli wydajności i optymalizacja tylko tam, gdzie jest to potrzebne.
Keith,
40

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
lomaxx
źródło
1
dla mnie bezpieczeństwo czasu kompilacji jest kluczowe!
bbqchickenrobot
W przypadku wdrażania, jeśli jednak pracujesz w zespole korporacyjnym, który ma cykl wdrażania i istnieje błąd, który musi zostać szybko usunięty, wdrożenie bibliotek DLL za pomocą kontroli jakości itp. Jest prawdopodobnie bardziej rygorystyczne niż ścieżka do wdrożenia pojedynczej bazy danych scenariusz. Wydaje się, że twoje zalety lepiej odzwierciedlają scenariusz dla małego zespołu / projektu.
SnapJag
3
Wdrożenie skryptów SQL, które nie muszą przechodzić kontroli jakości, niekoniecznie jest tutaj dobrą rzeczą.
liang
27

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

SQLMenace
źródło
10
Co za głupi argument - po prostu użyj zmiennej, a twój problem zostanie rozwiązany.
JohnOpincar
6
@John, nie pomogłoby to, gdybyś użył sprawdzania poprawności zamiast literału, ponieważ na końcu wysyłasz literalny ciąg do bazy danych. może to wyglądać jak zmienna w twoim kodzie, ale będzie to ciąg znaków w wygenerowanym T-SQL, który zostanie wysłany do bazy danych.
kay.one
15
SQLMenace: W zależności od strony, do której prowadzisz link, problem został rozwiązany w VS2010.
Mark Byers,
8
Ten problem był ważny, gdy odpowiedź została opublikowana, ale od tego czasu została rozwiązana w VS2010, więc nie jest już problemem.
Brain2000
17

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ę;)

Dr8k
źródło
4
Nauka LINQ nie jest niczym wielkim - to tylko cukier składniowy. TSQL to zupełnie inny język. Jabłka i Pomarańcze.
Adam Lassek
3
Zaletą uczenia się LINQ jest to, że nie jest on związany z jedną technologią - semantyka zapytań może być używana w XML, obiektach itp., A to z czasem się powiększy.
Dave R.,
5
Zgoda! Tak wiele osób (programistów) szuka rozwiązania „szybkiego wprowadzania na rynek” w małych zespołach i projektach. Ale jeśli rozwój zostanie przeniesiony na wyższy poziom stylu korporacyjnego z wieloma zespołami, dużymi bazami danych, wysokonakładowymi, wysokowydajnymi, rozproszonymi systemami, użycie LINQ będzie inną historią! Nie sądzę, że będziesz musiał zbyt długo edytować swoją opinię. LINQ nie jest przeznaczony dla projektów / zespołów, które są większe i mają wiele osób, wiele zespołów (Dev i DBA) ORAZ mają ścisły harmonogram wdrażania.
SnapJag
17

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ć.


źródło
2
łatwo jest zawieść dzięki wskaźnikom w C / C ++ / C # czy to oznacza, że ​​nigdy nie należy go używać?
bbqchickenrobot
1
Ilu programistów średniego szczebla ma do czynienia ze wskaźnikami? Linq udostępnia tę funkcję każdemu koderowi poziomu, co oznacza, że ​​ryzyko błędu dramatycznie wzrasta.
Jacques
1
Porównujesz początkujących w LINQ ze starszym facetem TSQL. Niezupełnie uczciwe porównanie. Zgadzam się z twoim kodem, LINQ ogólnie nie działa w przypadku aktualizacji / usuwania partii. Jednak argumentowałbym, że większość argumentów dotyczących wydajności między LINQ a SP to twierdzenia, ale nie oparte na miarach
liang
12

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.

Mark Cidade
źródło
10

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?


źródło
2
Poruszasz dobrą rację; LINQ nie jest alternatywą w tym przypadku.
Meta-Knight
1
Różne aplikacje powinny korzystać ze wspólnej warstwy dostępu do danych (oczywiście nie zawsze tak jest). Jeśli tak, to możesz wprowadzić jedną zmianę do wspólnej biblioteki i ponownie wdrożyć. Możesz także użyć czegoś takiego jak WCF, aby obsłużyć dostęp do danych. Jest ładna warstwa abstrakcji, która technicznie mogłaby użyć linq, aby uzyskać dostęp do danych za kulisami. Myślę, że wszystko zależy tylko od tego, co wymyślą twoi faceci dla twoich wymagań w odniesieniu do używania SP przeciwko Linq.
bbqchickenrobot
8

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.

lomaxx
źródło
7

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.

Craig
źródło
3
Tak, my, DBA, czekamy cały dzień, aż poprosisz o przekazanie przechowywanego Proc do produkcji. Brak konieczności złamania naszych serc!
Sam
6

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.

Todd Bandrowsky
źródło
5

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.

Kenny
źródło
4

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.

DylanWoods
źródło
3

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.

Jon Limjap
źródło
1
Ponieważ więcej miejsc niż aplikacja może wpływać na dane - import danych, inne aplikacje, bezpośrednie zapytania itp. Głupotą jest nie umieszczanie logiki biznesowej w bazie danych. Ale jeśli integralność danych nie stanowi dla ciebie problemu, śmiało.
HLGEM
3
Logika biznesowa nie powinna wchodzić do bazy danych. Powinien być w języku programowania, w którym można go łatwo debugować i zarządzać. Następnie można go udostępniać w aplikacjach jako obiekty. Niektóre reguły mogą znajdować się w bazie danych, ale nie logiki biznesowej.
4thSpace
3

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

Kyaw Thura
źródło
1
przyjaciele zginęli podczas jazdy na motocyklach: P
Alex
2
ludzie również zginęli, prowadząc samochód.
liang
1
tak, mylisz się
Asad Ali
3

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. :)

Manish
źródło
4
Ładowanie wszystkiego do pamięci i filtrowanie? Linq może wysłać filtr jako część zapytania do bazy danych i zwraca przefiltrowany zestaw wyników.
liang
istnieje wiele osób, które uważają, że LINQ ładuje wszystkie dane i przetwarza je za pomocą pętli foreach. To jest źle. Po prostu kompiluje się w kwerendę SQL i zapewnia prawie taką samą wydajność dla większości operacji CRUD. Ale tak, to nie jest srebrna kula. Są przypadki, w których użycie T-SQL lub przechowywanych procesów może okazać się lepsze.
To pułapka
Zgadzam się na oba kontrargumenty. Jednak nie jest do końca prawdą, że linq wysyła wszystkie filtry do DBMS, aby nad nim pracować. Jest kilka rzeczy, które działają w pamięci, jedna z nich jest odrębna.
Manish
2

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.

Neo
źródło
2

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.

dansasu11
źródło
1

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.

pokrate
źródło
1
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

totaldonet
źródło
4
Jaki jest sens tego?
Teoman shipahi
0

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.

żywa miłość
źródło