Wann sollten Sie ORM nicht verwenden und gespeicherte Prozeduren bevorzugen?

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.

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.

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.

Einfache Abfrage -> ORM

Komplexe Abfrage -> Gespeicherte Prozedur

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

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