Kiedy nie używać ORM i preferować procedury składowane?

13

Używam PetaPoco micro-ORM. Praca z bazami danych za pomocą narzędzi ORM jest naprawdę bardzo łatwa i bezpieczna, ale nienawidzę tylko dodatkowego kodu. Zwykle umieszczałem większość kodu w samej bazie danych i korzystałem ze wszystkich funkcji RDBMS, takich jak Procedury składowane, Wyzwalacze itp., Które zostały zbudowane w celu lepszej obsługi.

Chcę wiedzieć, kiedy nie używać ORM zamiast przechowywanych procedur / wyzwalaczy i odwrotnie.

orm rdbms stored-procedures RPK
źródło
6
Osobiście mój problem z wyzwalaczami (w szczególności nie dotyczy procedur przechowywanych) polega na tym, że próbują „odgadnąć”, co się stało z „działaniem biznesowym” na podstawie sposobu manipulowania danymi w bazie danych. Jeśli zmodyfikujesz kolumnę CENA w tabeli „ARTYKUŁY”, to tak naprawdę nie wiesz, dlaczego tak jest. Czy użytkownik koryguje błędnie wpisaną wartość? Czy to jest obniżka? Czy to specjalna oferta, która obowiązuje tylko przez jeden dzień? Wyzwalacze muszą to wszystko odgadnąć .
Joachim Sauer

Odpowiedzi:

16

ORM (mapowanie obiektowo-relacyjne) nie wyklucza się wzajemnie z procedurami przechowywanymi. Większość ORM może wykorzystywać procedury składowane. Większość ORM generuje Procedury przechowywane, jeśli tak zdecydujesz. Więc problemem nie jest albo.

ORM mogą generować niedopuszczalny SQL (pod względem wydajności), a czasem możesz chcieć zastąpić ten SQL ręcznie spreparowanym SQL. Jednym ze sposobów osiągnięcia tego jest użycie SP (procedur przechowywanych).

W DotNet nie używaj procedur przechowywanych, jeśli:

  • Jeśli nie znasz procedur przechowywanych (nie swojej sprawy, ale uwzględniono ją dla kompletności).

  • Jeśli nie chcesz wprowadzać warstwy złożoności i dostosowywania do swojego projektu.

  • Tworzysz aplikację, która powinna współpracować z różnymi bazami danych lub która musiałaby zostać zreplikowana na kilku serwerach baz danych (to ostatnie ograniczenie może dotyczyć tylko niektórych baz danych).

Pamiętaj, że wyzwalaczy nie należy porównywać z ORM. Wyzwalacze wykonują funkcje, których lepiej nie ma w kodzie aplikacji (takie jak rejestrowanie lub synchronizowanie danych między bazami danych).

Niektóre osoby wolą używać procedur przechowywanych zamiast kodu SQL z różnych powodów, takich jak bezpieczeństwo (na przykład, aby zapobiec wstrzykiwaniu SQL) i ze względu na deklarowaną szybkość. Jest to jednak nieco dyskusyjne i wymaga szczegółowej dyskusji.

Jeśli twój ORM nie może wygenerować Procedur Przechowywanych i musisz napisać duży system, musisz ważyć dodatkowe kodowanie ręczne na podstawie twojej sprawy.

Bez szans
źródło
2
Uważam, że argument bezpieczeństwa nie jest związany z wstrzykiwaniem SQL, ale raczej z uprawnieniami (tj. W większości przypadków zarządzanie uprawnieniami do konkretnej procedury składowanej dla użytkowników, którzy mają dostęp do bazy danych, jest proste, ale zarządzanie tymi uprawnieniami do tabel, kolumn i wiersze są albo trudniejsze, albo niemożliwe). Jednak argument dotyczący bezpieczeństwa pozostaje dyskusyjny.
Arseni Mourzenko
@MainMa, dzięki za komentarz. Rozumiem, że przy użyciu SP można zmniejszyć ryzyko wstrzyknięcia SQL przez zastosowanie sparametryzowanej procedury składowanej z osadzonymi parametrami, jak sugeruje ten artykuł: palpapers.plynt.com/issues/2006 Jun
stored
2
Procedury przechowywane praktycznie nie mają wpływu na podatność na ataki typu sql injection. Stare mity umierają ciężko.
Przypon
@Rig 1, dziękuję za komentarz, chcę dowiedzieć się więcej o tym, co o tym sądzisz. Rozumiem co najmniej z tego tekstu: „Możesz udaremnić ataki wstrzykiwania programu SQL Server, używając procedur przechowywanych i sparametryzowanych poleceń, unikając dynamicznego SQL i ograniczając uprawnienia wszystkim użytkownikom”. który pojawia się w msdn.microsoft.com/en-us/library/bb669057.aspx
NoChance
@EmmadKareem Sparametryzowany sql to duży krok w kierunku zapewnienia bezpieczeństwa. Myślę, że ten facet robi rozsądną sprawę palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Wyszukiwanie w nim spowoduje „Wstrzyknięcie SQL procedury przechowywanej” spowoduje wyświetlenie wielu trafień. Zawsze dobrze jest oczyścić swoje dane wejściowe, a wiele platform zapewnia wbudowane możliwości, aby zrobić to całkiem dobrze.
Przypon
13

ORM często zakładają, że baza danych istnieje, aby obsługiwać ORM. Ale zwykle baza danych istnieje po to, aby obsługiwać firmę, która może zawierać setki aplikacji napisanych w wielu językach.

Ale to tylko przypadek „ORM vs. Procedury składowane”, jeśli używasz ORM, który nie może wywołać procedury składowanej. W przeciwnym razie chodzi o decyzję, gdzie kodować logikę biznesową.

Gdziekolwiek kodujesz logikę biznesową, jej zadaniem jest upewnienie się, że baza danych zmienia się z jednego spójnego stanu na inny spójny stan, niezależnie od tego, która aplikacja wprowadza zmianę . Tak naprawdę masz tylko dwie praktyczne opcje - koduj raz w bazie danych lub koduj raz w „nieprzeniknionej” warstwie dostępu do danych.

Uważaj na interfejs wiersza poleceń dbms, jeśli używasz „nieprzeniknionego” DAL.

Mike Sherrill „Cat Recall”
źródło
4
Natknąłem się na więcej niż jeden przypadek, w którym stare SP i wyzwalacze musiały być używane z nowymi aplikacjami z powodu istniejących aplikacji starszych. Zaletą jest to, że logika biznesowa musi być utrzymywana tylko w jednym miejscu.
jfrankcarr
Zdecydowanie nie zaprzeczam, że została użyta „jedna baza danych, aby obsłużyć je wszystkie”, ale jest to głównie przeszłość, szczególnie dlatego, że utrzymanie staje się czystym piekłem, szczególnie gdy wiele aplikacji musi utrzymywać własną wersję przechowywanych proc. Posiadanie bazy danych do obsługi aplikacji, która jest jej właścicielem, jest znacznie bardziej nowoczesnym podejściem, ponieważ wymusza luźniejsze łączenie aplikacji i usług.
Flater
-1

Proste zapytanie -> ORM

Złożone zapytanie -> Procedura składowana

Ciemna noc
źródło
3
Gdzie kompleks wykonuje segregację od prostej kwerendy,
Independent
-2

Wyzwalacz powinien być używany jako niezmiennik zapisu lub składać się z podstawowych reguł biznesowych, IMHO.

Problemy z orms:

  1. Powinieneś ustawić uprawnienia dla tabel, a nie dla „akcji” (mam na myśli SP)
  2. Aby zmienić logikę rozwiązania, musisz zmienić kod w aplikacji, a następnie rozprowadzić go w sieci dla klientów
Jurij Wikulow
źródło
-5

Nie zgadzać się. Zapytanie ORM jest prostsze tylko wtedy, gdy znasz ORM lepiej niż SQL. W wyniku ORM powstaje znacznie więcej kodu, znacznie trudniej w utrzymaniu IMO. Jedynymi osobami korzystającymi z ORM są akcjonariusze firmy sprzedającej ORM (np. Microsoft).

Fantom
źródło
1
szkoda, że ​​opinia wyrażona w tej odpowiedzi nie jest poparta ani referencjami, ani doświadczeniem. W rezultacie będzie to bezużyteczne dla czytelnika, który może natknąć się na „odwrotne” twierdzenie, podobnie jak procedury składowane są korzystne tylko dla dostawców DB . Każe sobie sprawę, dlaczego poradnictwo w prawdziwych pytań odpowiedzi stwierdza: „prawdziwe pytania mają odpowiedzi , a nie przedmioty lub pomysły lub opinie ... ”
gnat