Gespeicherte Prozeduren oder OR-Mapper?

Question

Was ist besser? Oder verwenden und ODER mappen mit SP? Wenn Sie bereits ein System mit SPs haben, lohnt sich ein OR-Mapper?

Answer 1

Ich mag ORM, weil Sie das Rad nicht neu erfinden müssen. Davon abgesehen, hängt es vollständig von Ihren Anwendungsbedürfnissen, dem Entwicklungsstil und dem des Teams ab.

Diese Frage wurde bereits abgedeckt Why is parameterized SQL generated by NHibernate just as fast as a stored procedure?

Answer 2

Ich persönlich habe festgestellt, dass SPs eher leistungsfähig sind, zumindest für die großen Daten, die ich regelmäßig ausführe. Aber ich kenne viele Leute, die auf OP-Tools schwören und sonst nichts tun.

Answer 3

Stored Procedures sind besser, meiner Meinung nach, weil sie eine unabhängige Sicherheitskonfiguration aus den zugrundeliegenden Tabellen haben.

Dies bedeutet, dass Sie bestimmte Operationen zulassen können, ohne Schreib-/Lesevorgänge für bestimmte Tabellen zuzulassen. Es begrenzt auch den Schaden, den Menschen tun können, wenn sie einen SQL-Injection-Exploit entdecken.

Answer 4

Ich würde behaupten, dass die Verwendung eines OR-Mappers die Lesbarkeit und Wartbarkeit des Quellcodes Ihrer Anwendungen erhöht, während die Verwendung von SP die Leistung der Anwendung erhöht.

Answer 5

Gespeicherte Prozeduren übersichtlich. OR-Mapper sind sprachspezifisch und fügen oft grafische Verlangsamungen hinzu.

Gespeicherte Prozeduren bedeutet, dass Sie nicht durch die Sprachschnittstelle eingeschränkt sind, und Sie können lediglich neue Schnittstellen zu der Datenbank auf vorwärts kompatible Weise anheften.

Meine persönliche Meinung von OR Mappers ist ihre Existenz unterstreicht einen Designfehler in der populären Struktur von Datenbanken. Datenbankentwickler sollten die Aufgaben verstehen, die Menschen mit komplizierten OR-Mappers erreichen wollen, und serverseitige Dienstprogramme erstellen, die bei der Durchführung dieser Aufgabe helfen.

OR Mapper sind auch epische Ziele der „leaky Abstraktion“ Syndrom (Joel On Software: Leaky Abstractions)

Wo seine ganz einfach Dinge, die es einfach nicht handle, weil die Abstraktionsschicht ist psychisch nicht zu finden.

Answer 6

Sie schließen sich eigentlich nicht gegenseitig aus, obwohl das normalerweise so ist.

Der Vorteil der Verwendung von Object Relational Mapping besteht darin, dass Sie Datenquellen austauschen können. Nicht nur Datenbankstruktur, sondern Sie können jede Datenquelle verwenden. Mit Advent Web Services/Service-orientierte Architektur/ESB, in einem größeren Unternehmen, wäre es ratsam zu erwägen, eine höhere Ebene Trennung von Anliegen als was Sie in gespeicherten Prozeduren erhalten könnten. In kleineren Unternehmen und in Anwendungen, die nie eine andere Datenquelle verwenden, können SPs jedoch die Rechnung gut anpassen. Und ein letzter Punkt, es ist nicht notwendig, einen OR-Mapper zu verwenden, um die Abstraktion zu erhalten. Mein ehemaliges Team hatte großen Erfolg, indem ich einfach ein Adaptermodell mit Spring.NET verwendete, um die Datenquelle zu verbinden.

Answer 7

Definitiv ORMs. Flexibler, portabler (in der Regel sind sie portabel). Im Falle von Langsamkeit möchten Sie möglicherweise Caching oder manuell abgestimmte SQL in Hotspots verwenden.

Im Allgemeinen gespeicherte Prozeduren haben mehrere Probleme mit der Wartbarkeit.

• getrennt von Anwendung (so viele Veränderungen haben nun an zwei Stellen durchgeführt werden)
• im Allgemeinen schwieriger zu
• härter zu ändern, unter Versionskontrolle stellen wollen
• schwieriger sicherzustellen, dass sie aktualisiert (Bereitstellungsprobleme)
• Portabilität (bereits erwähnt)

Answer 8

Dies wurde ausführlich auf vorherige Fragen diskutiert.

What are the pros and cons to keeping SQL in Stored Procs versus Code

Answer 9

@ Kent Fredrick

Meine persönliche Meinung OR Mapper ist ihre Existenz einen Designfehler in der beliebten Struktur von Datenbanken“

unterstreicht Ich glaube, Sie sprechen über den Unterschied zwischen dem relationalen Modell und dem objektorientierten Modell, das ist der Grund, warum wir ORMs brauchen, aber die Implementierungen dieser Modelle wurden absichtlich durchgeführt - es ist kein Designflow - es ist nur wie Dinge erwiesen sich als historisch.

Answer 10

Verwenden Sie gespeicherte Prozeduren, bei denen Sie einen Leistungsengpass festgestellt haben. Wenn Sie keinen Engpass erkannt haben, was tun Sie bei einer vorzeitigen Optimierung?
Verwenden Sie gespeicherte Prozeduren, bei denen Sie Bedenken hinsichtlich des Sicherheitszugriffs auf eine bestimmte Tabelle haben.
Verwenden Sie gespeicherte Prozeduren, wenn Sie über einen SQL-Assistenten verfügen, der bereit ist, komplexe Abfragen zu erstellen, die eine große Anzahl von Tabellen in einer Legacy-Datenbank zusammenfassen, um die Aufgaben in einem OR-Mapper zu erledigen.

Verwenden der OR-Mapper für das andere (mindestens) 80% Ihrer Datenbank: wo die wählen und Updates so Routinen sind als Zugang über gespeicherte Prozeduren allein eine sinnlose Übung in manueller Codierung zu machen, und wo Updates sind so selten dass es keine Leistungskosten gibt. Verwenden Sie einen OR-Mapper, um die einfachen Dinge zu automatisieren.

Die meisten OR-Mapper können mit gespeicherten Procs für den Rest sprechen.

Sie sollten keine gespeicherten Prozeduren verwenden, vorausgesetzt, sie sind schneller als eine SQL-Anweisung in einer Zeichenfolge, dies ist in den letzten Versionen von MS SQL Server nicht unbedingt der Fall.

Sie müssen keine gespeicherten Prozeduren verwenden, um SQL Injection-Angriffe zu vereiteln. Es gibt andere Möglichkeiten, um sicherzustellen, dass Ihre Abfrageparameter stark typisiert sind und nicht nur mit einer Zeichenfolge verkettet sind.

Sie müssen keinen OR-Mapper verwenden, um ein POCO-Domänenmodell zu erhalten, aber es hilft.

Answer 11

Wenn Sie bereits eine Daten-API haben, die als Sprocs verfügbar gemacht wird, müssen Sie eine größere Überarbeitung der Architektur rechtfertigen, um zu ORM zu gelangen.

Für eine grün-Felder bauen, habe ich mehrere Dinge bewerten würde:

1. Wenn es im Team ein dedizierter DBA ist, würde ich lehnen
2. sprocs Wenn es zu berühren mehr als eine Anwendung ist die gleiche DB ich würde lehnen
3. sprocs Wenn es keine Möglichkeit der Datenbankmigration je lehne ich mich würde zu sprocs
4. Wenn ich versuche MVCC in der DB zu implementieren, ich sprocs anlehnen würde
5. Wenn ich dies als eine Prod Da ich möglicherweise mehrere Backend-dbs (MySql, MSSql, Oracle) habe, würde ich mich an ORM orientieren.
6. Wenn ich eine knappe Frist habe, würde ich mich an ORM orientieren, da es ein schnelleres Verfahren zum Erstellen meines Domänenmodells ist Halten Sie es synchron mit dem Datenmodell (mit geeigneten Werkzeugen).
7. Wenn ich das gleiche Domain-Modell auf mehrere Arten offenlege (Web-App, Web-Service, RIA-Client), orientiere ich mich an ORM, denn dann ist das Datenmodell hinter meiner ORM-Fassade versteckt, was ein robustes Domain-Modell ist wertvoller für mich.

Ich denke, Leistung ist ein bisschen ein Red Hering; Hibernate scheint fast genauso gut oder besser zu funktionieren als handcodiertes SQL (aufgrund seiner Caching-Ebenen), und es ist einfach, in Ihrem Sproc eine falsche Abfrage zu schreiben.

Die wichtigsten Kriterien sind wahrscheinlich die Fähigkeiten des Teams und langfristige Datenbankportabilität.

Answer 12

Nun, die SP sind schon da. Es macht keinen Sinn, sie wirklich zu können. Ich denke, macht es Sinn, einen Mapper mit SPs zu verwenden?

Answer 13

"Ich versuche in einen Nagel zu fahren. Soll ich den Absatz meines Schuhs oder eine Glasflasche benutzen?"

Sowohl Stored Procedures als auch ORMs sind für einen Entwickler schwierig und ärgerlich (wenn auch nicht notwendigerweise für einen DBA oder einen Architekten), da sie Anlaufkosten und höhere Wartungskosten verursachen, die keine Bezahlung garantieren -aus.

Beide werden sich auszahlen, wenn die Anforderungen nicht viel über die Lebensdauer des Systems ändern, aber sie werden Ihnen in den Weg kommen, wenn Sie das System erstellen, um die Anforderungen in erster Linie zu entdecken.

Straight-coded SQL oder Quasi-ORM wie LINQ und ActiveRecord ist besser für Build-to-Discovery-Projekte (die im Unternehmen viel mehr passieren, als die PR möchte Sie denken).

Gespeicherte Prozeduren sind besser in einer sprachunabhängigen Umgebung, oder wo eine fein abgestimmte Kontrolle über Berechtigungen erforderlich ist. Sie sind auch besser, wenn Ihr DBA die Anforderungen besser versteht als Ihre Programmierer.

Vollwertige ORMs sind besser, wenn Sie Big Design Up Front verwenden, viel UML verwenden, das Datenbank-Back-End abstrahieren möchten und Ihr Architekt die Anforderungen besser versteht als Ihr DBA oder Programmierer.

Und dann gibt es Option # 4: Verwenden Sie alle von ihnen. Ein ganzes System ist normalerweise nicht nur ein Programm, und obwohl viele Programme mit der gleichen Datenbank kommunizieren, könnten sie jeweils die Methode verwenden, die sowohl für die spezifische Aufgabe des Programms als auch für seinen Reifegrad geeignet ist. Das heißt: Sie beginnen mit geradlinig codiertem SQL oder LINQ, dann reifen Sie das Programm durch Refactoring in ORM und Stored Procedures, wo Sie sehen, dass sie sinnvoll sind.

Answer 14

Bei meiner Arbeit machen wir hauptsächlich Geschäftsanwendungen - Vertragsarbeit.

Für diese Art von Geschäft bin ich ein großer Fan von ORM. Vor etwa vier Jahren (als die ORM-Tools weniger ausgereift waren) haben wir uns mit CSLA beschäftigt und unser eigenes vereinfachtes ORM-Tool eingeführt, das wir in den meisten unserer Anwendungen verwenden, einschließlich einiger Systeme der Unternehmensklasse mit über 100 Tabellen.

Wir schätzen, dass dieser Ansatz (der natürlich viel Codegenerierung beinhaltet) eine Zeitersparnis von bis zu 30% in unseren Projekten ermöglicht. Ernsthaft, es ist lächerlich.

Es gibt eine kleine Leistungseinbußen, aber es ist unerheblich, solange Sie ein gutes Verständnis der Softwareentwicklung haben. Es gibt immer Ausnahmen, die Flexibilität erfordern.

Zum Beispiel sollten extrem datenintensive Batch-Operationen nach Möglichkeit immer noch in spezialisierten Sprocs abgewickelt werden. Sie wollen wahrscheinlich nicht 100.000 riesige Datensätze über den Draht senden, wenn Sie es in einem Sproc direkt in der Datenbank tun könnten.

Dies ist die Art von Problem, dass Anfänger Devices run, ob sie ORM verwenden oder nicht. Sie müssen nur die Ergebnisse sehen und wenn sie kompetent sind, werden sie es bekommen.

Was wir in unseren Web-Apps gesehen haben, ist, dass die am schwierigsten zu lösenden Performance-Engpässe selbst mit ORM nicht länger datenbankbezogen sind. Eher, ty're auf dem Front-End (Browser) wegen der Bandbreite, AJAX Overhead, etc. Selbst Mid-Range-Datenbank-Server sind heutzutage unglaublich mächtig.

Natürlich können andere Geschäfte, die auf viel größeren High-Demand-Systemen arbeiten, unterschiedliche Erfahrungen dort haben. :)

Answer 15

Es gibt nichts Gutes über gespeicherte Prozeduren zu sagen. Es gab eine Notwendigkeit vor 10 Jahren, aber jeder einzelne Vorteil der Verwendung von Sprocs ist nicht mehr gültig. Die zwei häufigsten Argumente sind Sicherheit und Leistung. Der "sending stuff over the wire" -Mist hält auch nicht, ich kann natürlich dynamisch eine Abfrage erstellen, um alles auch auf dem Server zu machen. Eine Sache, die die Sproc-Befürworter Ihnen nicht sagen werden, ist, dass es Aktualisierungen unmöglich macht, wenn Sie die Konfliktauflösung für eine Merge-Publikation verwenden. Nur DBAs, die denken, sie seien der Overlord der Datenbank, bestehen auf Sprocs, weil sie ihren Job beeindruckender erscheinen lassen als er wirklich ist.