Vielleicht ist es sinnvoll, die Frage umzudrehen und nach Anwendungsfällen zu suchen, in denen nur gespeicherte Prozeduren das tun können, was Sie erreichen möchten. Vielleicht gibt es wirklich Anwendungsfälle, in denen gespeicherte Prozeduren auffallen.
Wenn es einen Unterschied macht, verwende ich MSSQL und Entity Framework.
Mein Wissen über EF ist begrenzt, aber soweit ich sehen kann, ist EF ( nur ) ein ORM wie jeder andere. und ist glücklicherweise in der Lage, rohes SQL zu verwenden .
Wenn ich Ihre zwei Hauptpunkte nehme:
Ein komplizierter Bericht, dessen Ausführung einige Minuten in Anspruch nahm (dies war eine Seite in einer Web-App). Ich fand heraus, dass ich SQL schreiben konnte, das viel effizienter war (nur wenige Sekunden) als das, was LINQ bereitstellte.
LINQ / EF hat bei der Erstellung eines Berichts versagt. Und wie Sie bemerkt haben, war es SQLviel schneller als mit einem ORM. Aber spricht dies für gespeicherte Prozeduren oder nur gegen die Verwendung des ORM für alles?
Ihr Problem könnte offensichtlich mit SQL gelöst werden . Wenn diese Abfrage in Ihrer Codebasis gespeichert und versionskontrolliert wurde, macht dies - gemäß Ihrem Beispiel - zumindest keinen Unterschied .
Eine Webanwendung musste einige Tabellen in einer separaten Datenbank lesen und in diese schreiben, die viele andere vertrauliche Informationen enthielt, die für die Anwendung nicht relevant waren. Anstatt ihm Zugriff auf alles zu gewähren, habe ich eine gespeicherte Prozedur verwendet, die nur das tut, was benötigt wird, und nur begrenzte Informationen zurückgibt. Die Webanwendung kann dann nur auf diese gespeicherte Prozedur zugreifen, ohne auf Tabellen usw. zuzugreifen.
Gleiches hier: eine einfache Verbindungszeichenfolge und und UPDATE und dein Problem ist erledigt. Dieses Problem könnte sogar mit einem ORM gelöst werden :
Verwenden Sie einfach einen Webservice vor der anderen DB und die gleiche Unterteilung / Isolation wird erreicht.
Also hier nichts zu sehen.
Blick auf einige Punkte, die andere gemacht haben:
Sie haben komplexe Arbeitseinheiten, an denen möglicherweise viele Tabellen beteiligt sind, die mit den Funktionen von EF nicht einfach in eine Transaktion eingebunden werden können.
Aber das SQLkann man machen. Hier geht es nicht um Magie .
Ihre Datenbank spielt nicht gut mit EF
Nochmals: Verwenden Sie gegebenenfalls EF .
Sie müssen mit Daten arbeiten, die Servergrenzen mit Verbindungsservern überschreiten
Ich sehe nicht, wie gespeicherte Prozeduren helfen. So kann ich nicht sehen einen Vorteil von gespeicherten Prozeduren; aber vielleicht bringt jemand etwas Licht ins Dunkel.
Sie haben sehr komplexe Datenabrufszenarien, in denen "Bare-Metal" -SQL erforderlich ist, um eine angemessene Leistung sicherzustellen
Nochmals: "Grenzen von EF ".
Ihre Anwendung verfügt nicht über die vollständigen CRUD-Berechtigungen für eine Tabelle, kann jedoch in einem Sicherheitskontext ausgeführt werden, dem Ihr Server vertraut
Okay. Ich gehe mit einem vielleicht .
Bisher wurde nur ein halber Punkt für gespeicherte Prozeduren gemacht.
Möglicherweise gibt es Leistungsüberlegungen, die für gespeicherte Prozeduren sprechen.
1) Das Speichern von Abfragen bietet den Vorteil eines einfachen Aufrufs der gespeicherten Prozedur, der die Komplexität zusammenfasst. Da der Abfrageplaner die Abfrage kennt, ist die Optimierung "einfacher". Aber die Speicher sind mit dem aktuellen hochentwickelten Abfrageplaner _minimal.
Darüber hinaus ist die Datenbank selbst bei geringen Kosten für Ad-hoc- Abfragen, wenn Ihre Daten gut strukturiert und sorgfältig indiziert sind, lediglich der Engpass Ihrer Anwendung. Selbst wenn es ein kleines Delta gibt, ist es unter Berücksichtigung anderer Faktoren vernachlässigbar.
2) Trotzdem wurde argumentiert, komplexe Abfragen in einer DB zu speichern . Es gibt zwei Dinge zu beachten:
a) Komplexe Abfragen nutzen massiv die DB-Infrastruktur, was die Antwortzeiten für jede andere Abfrage erhöht. Sie können nicht viele laufen teure Abfragen in parallel . Das spricht weder pro noch contra gespeicherte Prozeduren, sondern gegen komplexe Abfragen.
b) Wenn die Abfrage trotzdem einige Zeit in Anspruch nimmt, warum stört es Sieger einer gespeicherten Prozedur mit geringer Geschwindigkeit?
tl; dr
Nichts spricht direkt gegen gespeicherte Prozeduren. Die Verwendung gespeicherter Prozeduren ist also in Ordnung - wenn es Sie glücklich macht.
Aber auf der anderen Seite: Ich konnte mir keinen richtigen Anwendungsfall vorstellen, der eindeutig pro spricht .
Wann sollte ich gespeicherte Prozeduren verwenden?
Die richtige Antwort lautet: Wann immer Sie möchten . Es gibt aber auch andere Möglichkeiten.