Verwenden Sie ein ORM oder einfaches SQL? [geschlossen]

Für einige der Apps, die ich entwickelt habe (und die ich dann vergessen habe), habe ich einfaches SQL geschrieben, hauptsächlich für MySQL. Obwohl ich ORMs in Python wie SQLAlchemy verwendet habe , habe ich mich nicht lange daran gehalten. Normalerweise war es entweder die Dokumentation oder die Komplexität (aus meiner Sicht), die mich zurückhielt.

Ich sehe das so: Verwenden Sie ein ORM für die Portabilität, einfaches SQL, wenn nur ein Datenbanktyp verwendet wird. Ich bin wirklich auf der Suche nach Ratschlägen zur Verwendung eines ORM oder SQL bei der Entwicklung einer App, die Datenbankunterstützung benötigt.

Wenn Sie darüber nachdenken, ist es weitaus besser, nur einen einfachen Wrapper zu verwenden, um Datenbankinkonsistenzen zu behandeln, als einen ORM zu verwenden.

ORMs haben einige nette Funktionen. Sie können einen Großteil der Arbeit beim Kopieren von Datenbankspalten in Objektfelder erledigen. In der Regel werden die Datums- und Uhrzeittypen der Sprache in den entsprechenden Datenbanktyp konvertiert. Sie behandeln im Allgemeinen auch Eins-zu-Viele-Beziehungen ziemlich elegant, indem sie verschachtelte Objekte instanziieren. Ich habe festgestellt, dass das Entwerfen Ihrer Datenbank unter Berücksichtigung der Stärken und Schwächen des ORM viel Arbeit beim Ein- und Auslesen von Daten in die Datenbank spart. (Sie möchten wissen, wie es mit Polymorphismus und vielen-zu-vielen-Beziehungen umgeht, wenn Sie diese abbilden müssen. Es sind diese beiden Domänen, die den größten Teil der "Impedanzfehlanpassung" bewirken, die manche ORM als "Vietnam der Informatik" bezeichnen. .)

Bei transaktionalen Anwendungen, dh Sie stellen eine Anfrage, rufen einige Objekte ab, durchlaufen sie, um Daten abzurufen und auf einer Webseite zu rendern. Die Leistungssteuer ist gering, und in vielen Fällen kann ORM schneller sein, da Objekte zwischengespeichert werden zuvor gesehen, hätte das sonst die Datenbank mehrmals abgefragt.

Für Anwendungen, die viel Bericht erstatten oder eine große Anzahl von Datenbankzeilen pro Anforderung verarbeiten, ist die ORM-Steuer viel höher, und das Caching, das sie durchführen, wird zu einer großen, nutzlosen Speicherlast. In diesem Fall ist eine einfache SQL-Zuordnung (LinQ oder iBatis) oder handcodierte SQL-Abfragen in einem Thin DAL der richtige Weg.

Ich habe festgestellt, dass Sie für jede groß angelegte Anwendung beide Ansätze verwenden. (ORM für einfaches CRUD und SQL / Thin DAL für die Berichterstellung).

Wenn ich als jemand spreche, der viel Zeit mit JPA (Java Persistence API, im Grunde die standardisierte ORM-API für Java / J2EE / EJB) verbracht hat, zu der Hibernate, EclipseLink, Toplink, OpenJPA und andere gehören, teile ich einige meiner Beobachtungen.

1. ORMs sind nicht schnell. Sie können angemessen sein und sind meistens in Ordnung, aber in einer Umgebung mit hohem Volumen und geringer Latenz sind sie ein Nein-Nein.
2. In allgemeinen Programmiersprachen wie Java und C # benötigen Sie eine Menge Magie, damit sie funktionieren (z. B. Weben in Java, Instrumentierung usw.).
3. Wenn Sie ein ORM verwenden, anstatt sich weiter von SQL zu entfernen (was die Absicht zu sein scheint), werden Sie erstaunt sein, wie viel Zeit Sie damit verbringen, XML und / oder Anmerkungen / Attribute zu optimieren, damit Ihr ORM performantes SQL generiert.
4. Für komplexe Abfragen gibt es wirklich keinen Ersatz. Wie in JPA gibt es einige Abfragen, die in Raw SQL einfach nicht möglich sind, und wenn Sie Raw SQL in JPA verwenden müssen, ist es nicht schön (C # /. Net hat zumindest dynamische Typen - var - was sehr viel ist schöner als ein Objektarray);
5. Bei der Verwendung von ORMs gibt es sehr viele "Fallstricke". Dies schließt unbeabsichtigtes oder unerwartetes Verhalten ein, die Tatsache, dass Sie die Fähigkeit zum Ausführen von SQL-Updates für Ihre Datenbank (mithilfe von refresh () in JPA oder ähnlichen Methoden einbauen müssen, da JPA standardmäßig alles zwischenspeichert, damit keine direkte Datenbank abgefangen wird Update - Das Ausführen direkter SQL-Updates ist eine häufige Aktivität zur Produktionsunterstützung.
6. Die objektrelationale Nichtübereinstimmung wird immer Probleme verursachen. Bei einem solchen Problem besteht ein Kompromiss zwischen Komplexität und Vollständigkeit der Abstraktion. Manchmal hatte ich das Gefühl, dass JPA zu weit gegangen ist und ein echtes Gesetz zur Verringerung der Rendite getroffen hat, bei dem die Komplexität nicht durch die Abstraktion gerechtfertigt war.

Es gibt noch ein anderes Problem, das etwas näher erläutert werden muss.

Das traditionelle Modell für eine Webanwendung besteht darin, eine Persistenzschicht und eine Präsentationsschicht zu haben (möglicherweise mit einem Dienst oder anderen Schichten dazwischen, aber dies sind die beiden wichtigsten für diese Diskussion). ORMs erzwingen eine starre Ansicht von Ihrer Persistenzschicht bis zur Präsentationsschicht (dh Ihren Entitäten).

Einer der Kritikpunkte an mehr rohen SQL-Methoden ist, dass Sie am Ende all diese VOs (Wertobjekte) oder DTOs (Datenübertragungsobjekte) haben, die von nur einer Abfrage verwendet werden. Dies wird als Vorteil von ORMs angepriesen, weil Sie das loswerden.

Diese Probleme verschwinden nicht mit ORMs, sondern gehen einfach auf die Präsentationsebene über. Anstatt VOs / DTOs für Abfragen zu erstellen, erstellen Sie benutzerdefinierte Präsentationsobjekte, normalerweise eines für jede Ansicht. Wie ist das besser IMHO ist es nicht.

Ich habe darüber in ORM oder SQL geschrieben: Sind wir schon da? .

Meine derzeitige Persistenztechnologie (in Java) ist ibatis. Es ist ein ziemlich dünner Wrapper um SQL, der mehr als 90% dessen leistet, was JPA kann (es kann sogar verzögertes Laden von Beziehungen durchführen, obwohl es nicht gut dokumentiert ist), aber mit weitaus weniger Aufwand (in Bezug auf Komplexität und tatsächlichen Code).

Dies kam letztes Jahr in einer GWT-Anwendung zum Ausdruck, die ich schrieb. Viele Übersetzungen von EclipseLink zu Präsentationsobjekten in der Service-Implementierung. Wenn wir ibatis verwendet hätten, wäre es viel einfacher gewesen, die entsprechenden Objekte mit ibatis zu erstellen und sie dann ganz nach oben und unten im Stapel zu übergeben. Einige Puristen könnten argumentieren, dass dies Bad ™ ist. Vielleicht (theoretisch), aber ich sage Ihnen was: Es hätte zu einfacherem Code, einem einfacheren Stack und mehr Produktivität geführt.

Ich sage schlicht SQL für R eads, ORM für CUD .

Die Leistung ist etwas, worüber ich mich immer Sorgen mache, insbesondere in Webanwendungen, aber auch die Wartbarkeit und Lesbarkeit von Code. Um diese Probleme zu beheben, habe ich SqlBuilder geschrieben .

ORM ist nicht nur Portabilität (was selbst mit ORMs schwer zu erreichen ist). Was es Ihnen gibt, ist im Grunde eine Abstraktionsebene über einem persistenten Speicher, wenn ein ORM-Tool Sie vom Schreiben von SQL-Abfragen auf Boilerplate befreit (Auswahl durch PK oder durch Prädikate, Einfügungen, Aktualisierungen und Löschungen) und Sie sich auf die Problemdomäne konzentrieren können.

Jedes seriöse Design benötigt eine gewisse Abstraktion für die Datenbank, um die Impedanzfehlanpassung zu bewältigen. Aber der einfachste erste Schritt (und für die meisten Fälle angemessen), den ich erwarten würde, wäre ein DAL, kein Schwergewichts-ORM. Ihre einzigen Optionen sind nicht die am Ende des Spektrums.

BEARBEITEN als Antwort auf einen Kommentar, in dem ich gebeten werde zu beschreiben, wie ich DAL von ORM unterscheide:

Ein DAL ist das, was Sie selbst schreiben, möglicherweise ausgehend von einer Klasse, die einfach eine Tabelle kapselt und ihre Felder Eigenschaften zuordnet. Ein ORM ist Code, den Sie nicht schreiben, oder Abstraktionsmechanismen, die aus anderen Eigenschaften Ihres DBMS-Schemas abgeleitet wurden, hauptsächlich PKs und FKs. (Hier erfahren Sie, ob die automatischen Abstraktionen undicht werden oder nicht. Ich informiere sie lieber absichtlich, aber das kann nur meine persönliche Präferenz sein.)

Jedes Werkzeug hat seinen Zweck und seine Vision. Ich habe http://www.jooq.org/ genau nach Ihren Wünschen erstellt, obwohl iBatis wahrscheinlich auch eine gute Lösung für Sie ist.

jOOQ verfügt über grundlegende ORM-Funktionen, konzentriert sich jedoch hauptsächlich auf die Dinge, die die meisten Entwickler meiner Meinung nach am meisten benötigen, wenn sie versuchen, das beste ORM für ihre Anforderungen zu finden:

• Codegenerierung
• variable Bindung (das ist ein Schmerz in JDBC)
• SQL-Syntaxabstraktion (um Syntaxfehler zu vermeiden)

Aber oft gehen sie zu weit und bieten so viel Abstraktion, dass man nicht glauben würde, dass sie gegen ein RDBMS laufen. Andererseits haben Sie sich genau deshalb für ein RDBMS entschieden

• Es ist eine robuste Datenquelle
• SQL kann viele gute, performante Dinge tun (verschachtelte Auswahlen, Vereinigungen, komplexe Verknüpfungen usw.). Oft können ORMs diese Dinge nicht tun.
• Sie können Transaktionen und Sitzungen selbst abwickeln
• Sie haben UDTs und gespeicherte Prozeduren

jOOQ spricht genau diese Punkte an. Es wird genauso gut funktionieren wie JDBC, aber ohne Schmerzen.

Das Dilemma, ob ein Framework verwendet werden soll oder nicht, ist im modernen Softwareentwicklungsszenario weit verbreitet.

Es ist wichtig zu verstehen, dass jedes Framework oder jeder Ansatz seine Vor- und Nachteile hat - zum Beispiel haben wir nach unserer Erfahrung festgestellt, dass ORM beim Umgang mit Transaktionen, dh beim Einfügen / Aktualisieren / Löschen von Vorgängen, nützlich ist -, aber beim Abrufen komplexer Daten Ergebnisse Es wird wichtig, die Leistung und Effektivität des ORM-Tools zu bewerten.

Es ist auch wichtig zu verstehen, dass es nicht obligatorisch ist, ein Framework oder einen Ansatz auszuwählen und alles darin umzusetzen. Damit meinen wir, dass wir eine Mischung aus ORM und nativer Abfragesprache haben können. Viele ORM-Frameworks geben Erweiterungspunkte für das Plugin in nativem SQL. Wir sollten versuchen, ein Framework oder einen Ansatz nicht zu stark zu nutzen. Wir können bestimmte Rahmenbedingungen oder Ansätze kombinieren und eine geeignete Lösung finden.

Sie können ORM verwenden, wenn es um das Einfügen, Aktualisieren, Löschen und Versionsversetzen mit hoher Parallelität geht, und Sie können Native SQL für die Berichterstellung und lange Auflistung verwenden

Der Schlüssel, der mein ORM wirklich zum Fliegen brachte, war die Codegenerierung. Ich bin damit einverstanden, dass die ORM-Route in Bezug auf die Codeleistung nicht die schnellste ist. Wenn Sie jedoch ein mittleres bis großes Team haben, ändert sich die Fähigkeit der Datenbank, Klassen und Zuordnungen aus der Datenbank als Teil des Erstellungsprozesses neu zu generieren, schnell. Dies ist besonders dann von Vorteil, wenn Sie CI verwenden. Ihr Code ist vielleicht nicht der schnellste, aber Ihr Code wird es sein - ich weiß, welchen ich in den meisten Projekten verwenden würde.

Meine Empfehlung ist, mithilfe eines ORM zu entwickeln, während das Schema noch flüssig ist, mithilfe von Profilen Engpässe zu finden und dann die Bereiche, die es benötigen, mithilfe von Raw-SQL zu optimieren.

Ein weiterer Gedanke: Das in Hibernate integrierte Caching kann bei richtiger Verwendung häufig zu massiven Leistungsverbesserungen führen. Kein Zurück mehr zur DB, um Referenzdaten zu lesen.

Es gibt keine "One-Tool-Fits-All" -Lösung, und dies gilt auch für die Frage "Soll ich ein oder / m verwenden oder nicht?" '.

Ich würde sagen: Wenn Sie eine Anwendung / ein Tool schreiben müssen, das / das sehr auf Daten ausgerichtet ist, ohne viel andere Logik, dann würde ich einfaches SQL verwenden, da SQL die domänenspezifische Sprache für diese Art von Anwendungen ist.

Wenn ich dagegen eine Geschäfts- / Unternehmensanwendung schreiben würde, die viel 'Domänen'-Logik enthält, würde ich ein reichhaltiges Klassenmodell schreiben, das diese Domäne in Code ausdrücken könnte. In einem solchen Fall kann ein OR / M-Mapper sehr hilfreich sein, um dies erfolgreich zu tun, da Sie viel Installationscode aus Ihren Händen nehmen müssen.

Eine der Apps, die ich entwickelt habe, war ein in Python geschriebener IRC-Bot. Die verwendeten Module werden in separaten Threads ausgeführt, aber ich habe keine Möglichkeit gefunden, mit Threading bei Verwendung von SQLite umzugehen. Für eine separate Frage könnte dies jedoch besser sein.

Ich hätte wirklich nur den Titel und die eigentliche Frage umformulieren sollen . Ich habe noch nie zuvor ein DAL in einer Sprache verwendet.

Verwenden Sie ein ORM, das wie SQL funktioniert , jedoch Überprüfungen zur Kompilierungszeit und Typensicherheit bietet. Wie mein Favorit: Data Knowledge Objects (Offenlegung: Ich habe es geschrieben)

Beispielsweise:

for (Bug bug : Bug.ALL.limit(100)) {
  int id = bug.getId();
  String title = bug.getTitle();
  System.out.println(id +" "+ title);
}

Vollständiges Streaming. Einfach einzurichten (keine Zuordnungen zu definieren - liest Ihre vorhandenen Schemata). Unterstützt Verknüpfungen, Transaktionen, innere Abfragen, Aggregation usw. So ziemlich alles, was Sie in SQL tun können. Und wurde von riesigen Datensätzen (Finanzzeitreihen) bis hin zu Trivial (Android) bewiesen.

Ich weiß, dass diese Frage sehr alt ist, aber ich dachte, ich würde eine Antwort posten, falls jemand wie ich darauf stößt. ORMs haben einen langen Weg zurückgelegt. Einige von ihnen bieten Ihnen tatsächlich das Beste aus beiden Welten: Produktivere Entwicklung und Aufrechterhaltung der Leistung.

Schauen Sie sich SQL Data an ( http://sqldata.codeplex.com ). Es ist ein sehr leichtes ORM für c #, das alle Basen abdeckt.

Zu Ihrer Information, ich bin der Autor von SQL Data.

Ich möchte meine Stimme dem Chor der Antworten hinzufügen, die sagen: "Es gibt einen Mittelweg!".

Für einen Anwendungsprogrammierer ist SQL eine Mischung aus Dingen, die Sie möglicherweise steuern möchten, und Dingen, die Sie mit ziemlicher Sicherheit nicht steuern möchten.

Was ich mir immer gewünscht habe, ist eine Ebene (nennen wir es DAL, ORM oder Mikro-ORM, es macht mir nichts aus, welche), die die vollständig vorhersehbaren Entscheidungen übernimmt (wie man SQL-Schlüsselwörter buchstabiert, wohin die Klammern gehen, wann Spaltenaliasnamen zu erfinden, welche Spalten für eine Klasse erstellt werden sollen, die zwei Gleitkommazahlen und eine int enthält ...), während ich für die übergeordneten Aspekte von SQL verantwortlich bin, dh wie JOINs angeordnet werden, serverseitige Berechnungen, UNTERSCHIEDE, GROUP BYs, skalare Unterabfragen usw.

Also habe ich etwas geschrieben, das dies tut: http://quince-lib.com/

Es ist für C ++: Ich weiß nicht, ob das die Sprache ist, die Sie verwenden, aber es könnte trotzdem interessant sein zu sehen, wie ein "Mittelweg" aussehen könnte.