Wann sollten Sie ORM nicht verwenden und gespeicherte Prozeduren bevorzugen?

13

Ich verwende PetaPoco Micro-ORM. Es ist zwar sehr einfach und sicher, mit ORM-Tools mit Datenbanken zu arbeiten, aber das einzige, was ich hasse, ist zusätzlicher Code. Früher habe ich den größten Teil des Codes in die Datenbank selbst gestellt und alle RDBMS-Funktionen wie gespeicherte Prozeduren, Trigger usw. verwendet, die besser verarbeitet werden können.

Ich möchte wissen, wann ORM nicht für gespeicherte Prozeduren / Trigger und umgekehrt verwendet werden soll.

RPK
quelle
6
Persönlich besteht mein Problem mit Triggern (gilt insbesondere nicht für gespeicherte Prozeduren) darin, dass sie versuchen, anhand der Manipulation der Daten in der Datenbank zu "erraten", welche "Geschäftsaktion" stattgefunden hat. Wenn Sie die Spalte PREIS in einer Tabelle "ARTIKEL" ändern, wissen Sie nicht wirklich, warum das so ist. Korrigiert der Benutzer nur einen falsch eingegebenen Wert? Ist das ein Abschlag? Ist es ein Sonderangebot, das nur einen Tag dauert? Trigger müssen das alles erraten .
Joachim Sauer

Antworten:

16

ORMs (Object Relational Mapping) schließen sich mit Stored Procedures nicht gegenseitig aus. Die meisten ORMs können gespeicherte Prozeduren verwenden. Die meisten ORMs generieren gespeicherte Prozeduren, wenn Sie dies wünschen. Also ist es das Thema entweder oder nicht.

ORMs können zu inakzeptablem SQL (in Bezug auf die Leistung) führen, und manchmal möchten Sie dieses SQL mit handgefertigtem SQL überschreiben. Eine Möglichkeit, dies zu erreichen, ist die Verwendung von SPs (Stored Procedures).

Verwenden Sie in DotNet keine gespeicherten Prozeduren, wenn:

  • Wenn Sie mit gespeicherten Prozeduren nicht vertraut sind (nicht Ihr Fall, aber der Vollständigkeit halber eingeschlossen).

  • Wenn Sie Ihrem Projekt keine Komplexität und Vielseitigkeit verleihen möchten.

  • Sie erstellen eine Anwendung, die mit verschiedenen Datenbanken arbeiten sollte oder die auf mehreren Datenbankservern repliziert werden müsste (diese letzte Einschränkung gilt möglicherweise nur für einige Datenbanken).

Beachten Sie, dass Trigger nicht mit ORMs verglichen werden dürfen. Trigger führen Funktionen aus, die sich besser nicht in Ihrem Anwendungscode befinden (z. B. Protokollieren oder Synchronisieren von Daten über Datenbanken hinweg).

Einige Benutzer bevorzugen die Verwendung gespeicherter Prozeduren gegenüber SQL im Code aus verschiedenen Gründen, z. B. aus Sicherheitsgründen (z. B. um SQL-Injection zu verhindern) und aufgrund der angegebenen Geschwindigkeit. Dies ist jedoch umstritten und bedarf einer eingehenden Diskussion.

Wenn Ihr ORM keine gespeicherten Prozeduren generieren kann und Sie ein großes System schreiben müssen, müssen Sie die zusätzliche Handcodierung basierend auf Ihrem Fall gewichten.

Keine Chance
quelle
2
Ich glaube, dass das Sicherheitsargument nicht mit SQL-Injection zusammenhängt, sondern mit den Berechtigungen (dh es ist meist einfach, Berechtigungen für eine bestimmte gespeicherte Prozedur für die Benutzer zu verwalten, die Zugriff auf die Datenbank haben, aber diese Berechtigungen für Tabellen, Spalten und Reihen ist entweder schwieriger oder unmöglich). Dennoch bleibt das Sicherheitsargument umstritten.
Arseni Mourzenko
@MainMa, danke für deinen Kommentar. Mein Verständnis ist, dass mit SPs das Risiko einer SQL-Injection durch die Verwendung einer parametrisierten gespeicherten Prozedur mit eingebetteten Parametern verringert werden kann, wie in diesem Artikel vorgeschlagen wird: palpapers.plynt.com/issues/2006Jun/injection-stored-procedures
NoChance
2
Gespeicherte Prozeduren haben praktisch keinen Einfluss auf die Anfälligkeit für SQL Injection-Angriffe. Alte Mythen sterben schwer.
Rig
@Rig 1, danke für deinen Kommentar, ich möchte mehr darüber erfahren, was du darüber denkst. Mein Verständnis ergibt sich (zumindest) aus diesem Text: "Sie können SQL Server-Injection-Angriffe durch Verwendung gespeicherter Prozeduren und parametrisierter Befehle verhindern, dynamisches SQL vermeiden und Berechtigungen für alle Benutzer einschränken." das erscheint in msdn.microsoft.com/en-us/library/bb669057.aspx
NoChance
@EmmadKareem Parametrisiertes SQL ist ein großer Schritt, um es sicher zu machen. Ich denke, dieser Typ macht einen vernünftigen Fall palpapers.plynt.com/issues/2006Jun/injection-stored-procedures . Eine Suche darauf wird "Stored Procedure SQL Injection" eine Menge Treffer aufdecken. Es ist immer gut, Ihre Eingaben zu bereinigen, und viele Plattformen bieten eine eingebaute Möglichkeit, dies recht gut zu tun.
Rig
13

ORMs gehen häufig davon aus, dass die Datenbank für den ORM vorhanden ist. In der Regel ist die Datenbank jedoch für das Unternehmen vorhanden, für das möglicherweise Hunderte und Hunderte von Apps in mehreren Sprachen geschrieben wurden.

Es handelt sich jedoch nur um "ORM vs. Gespeicherte Prozeduren", wenn Sie ein ORM verwenden, das keine gespeicherte Prozedur aufrufen kann. Andernfalls muss entschieden werden, wo die Geschäftslogik codiert werden soll.

Überall dort, wo Sie die Geschäftslogik codieren, muss sie sicherstellen, dass die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand wechselt, unabhängig davon, welche Anwendung die Änderung vornimmt . Sie haben also nur zwei praktische Möglichkeiten: Einmal in der Datenbank oder einmal in einer "undurchdringlichen" Datenzugriffsebene.

Achten Sie auf die DBMS-Befehlszeilenschnittstelle, wenn Sie eine "undurchdringliche" DAL verwenden.

Mike Sherrill 'Cat Recall'
quelle
4
Ich bin auf mehr als einen Fall gestoßen, in dem alte SPs und Trigger aufgrund vorhandener Legacy-Apps mit neuen Apps verwendet werden mussten. Der Vorteil ist, dass diese Geschäftslogik nur an einer Stelle gepflegt werden muss.
Jfrankcarr
Ich bestreite definitiv nicht, dass "eine Datenbank für alle" verwendet wurde, aber dies gehört größtenteils der Vergangenheit an, da die Wartung zur Hölle wird, insbesondere wenn mehrere Anwendungen ihre eigene Versionierung gespeicherter Prozesse verwalten müssen. Wenn die Datenbank für die Anwendung vorhanden ist, deren Eigentümer sie ist, ist dies ein viel modernerer Ansatz, da eine lockerere Kopplung zwischen Anwendungen und Diensten erzwungen wird.
Flater
-1

Einfache Abfrage -> ORM

Komplexe Abfrage -> Gespeicherte Prozedur

Dunkle Nacht
quelle
3
Wo Trennt sich ein Komplex von einer einfachen Abfrage?
Independent
-2

Der Trigger sollte als unveränderliche Aufzeichnung verwendet werden oder aus wichtigen Geschäftsregeln bestehen, IMHO.

Die Probleme von Orms:

  1. Sie sollten Berechtigungen pro Tabelle festlegen, nicht pro "Aktion" (ich meine SP)
  2. Um die Logik Ihrer Lösung zu ändern, müssen Sie den Code in Ihrer App ändern und ihn dann für Clients über das Netzwerk weitergeben
Yuriy Vikulov
quelle
-5

Nicht zustimmen. ORM-Abfrage nur einfacher, wenn Sie ORM besser kennen als SQL. ORM führt zu viel mehr Code, und es ist weitaus schwieriger, IMO zu verwalten. Die einzigen Personen, die von ORM profitieren, sind die Aktionäre des Unternehmens, das das ORM verkauft (z. B. Microsoft).

Phantom
quelle
1
Schade, dass die in dieser Antwort geäußerte Meinung weder durch Referenzen noch durch Erfahrung gestützt wird. Infolgedessen ist es für einen Leser nutzlos, wenn er auf eine "inverse" Behauptung stößt, von der gespeicherte Prozeduren nur DB-Anbietern zugute kommen . Lässt erkennen, warum Leitlinien in realen Fragen Antworten haben heißt: "reale Fragen haben Antworten , keine Elemente oder Ideen oder Meinungen ... "
Mücke