Vergleich von SQL, Abfrageerstellern und ORMs

Einführung

Die Verwendung einer Datenbank zur Verwaltung Ihrer Anwendungsdaten ist eine der häufigsten Optionen für die Datenpersistenz. Datenbanken ermöglichen schnelles Speichern und Abrufen von Informationen, bieten Datenintegritätsgarantien und bieten Persistenz über die Lebensdauer einer einzelnen Anwendungsinstanz hinaus. Es stehen unzählige Arten von Datenbanken zur Verfügung, um die Anforderungen Ihres Projekts und Ihre Präferenzen zu erfüllen.

Das direkte Arbeiten mit Datenbanken aus Ihrer Anwendung heraus ist jedoch nicht immer einfach. Unterschiede in der Darstellung von Datenstrukturen führen oft zu Herausforderungen. Die Schwierigkeit, Feinheiten über Beziehungen zwischen verschiedenen Entitäten auszudrücken, kann ebenfalls zu Problemen führen. Um dem entgegenzuwirken, wurden viele verschiedene Tools entwickelt, die dabei helfen, als Schnittstelle zwischen der Kernanwendung und der Datenschicht zu fungieren.

In diesem Leitfaden werden wir uns einige der Unterschiede ansehen, die sich zwischen drei gängigen Ansätzen ergeben:unformatiertes SQL, Abfrageersteller und ORMs (objektrelationale Mapper). Wir werden einige der Vor- und Nachteile der einzelnen Ansätze vergleichen und dann mit einem Glossar häufig verwendeter Begriffe abschließen, damit Sie sich mit einigen Schlüsselkonzepten vertraut machen können.

Als vereinfachte Zusammenfassung finden Sie hier eine allgemeine Übersicht über die Stärken und Schwächen der einzelnen Ansätze:

Verwaltung von Daten mit rohem SQL oder einer anderen datenbankeigenen Abfragesprache

Einige Anwendungen sind direkt mit der Datenbank verbunden, indem sie Abfragen unter Verwendung der von der Datenbank-Engine unterstützten Muttersprache schreiben und ausführen. Oft ist ein Datenbanktreiber alles, was benötigt wird, um sich mit der Datenbankinstanz zu verbinden, zu authentifizieren und zu kommunizieren.

Entwickler können über die Verbindung Abfragen senden, die in der Muttersprache der Datenbank geschrieben sind. Im Gegenzug liefert die Datenbank die Abfrageergebnisse, ebenfalls in einem ihrer nativen Formate. Für viele relationale Datenbanken ist SQL die Abfragesprache der Wahl.

Die meisten relationalen Datenbanken sowie einige nicht relationale Datenbanken unterstützen die strukturierte Abfragesprache, auch bekannt als SQL, um leistungsstarke Abfragen zu erstellen und auszuführen. SQL wird seit den 1970er Jahren zum Verwalten von Daten verwendet, daher ist es gut unterstützt und bis zu einem gewissen Grad standardisiert.

Vorteile der nativen Abfrage

Die Verwendung von SQL oder einer anderen datenbankeigenen Sprache hat einige klare Vorteile.

Ein Vorteil besteht darin, dass Entwickler die Datenbankabfragen schreiben und verwalten und die Ergebnisse explizit behandeln. Dies kann zwar viel zusätzliche Arbeit bedeuten, bedeutet aber, dass es nur wenige Überraschungen in Bezug darauf gibt, was die Datenbank speichert, wie sie Ihre Daten darstellt und wie sie diese Daten bereitstellt, wenn sie später abgerufen werden. Der Mangel an Abstraktion bedeutet, dass es weniger "bewegliche Teile" gibt, die zu Unsicherheit führen können.

Ein Beispiel dafür ist die Leistung. Während ausgeklügelte Abstraktionsschichten SQL-Abfragen durch Übersetzen von Programmieranweisungen generieren, kann das generierte SQL sehr ineffizient sein. Unnötige Klauseln, zu breite Abfragen und andere Pannen können zu langsamen Datenbankvorgängen führen, die anfällig und schwierig zu debuggen sind. Indem Sie nativ in SQL schreiben, können Sie Ihr gesamtes Domänenwissen und Ihren gesunden Menschenverstand einsetzen, um viele Arten von Abfrageproblemen zu vermeiden

Ein weiterer Grund für die Verwendung datenbanknativer Abfragen ist die Flexibilität. Wahrscheinlich ist keine Abstraktion so flexibel wie die native Datenbankabfragesprache. Höhere Abstraktionsebenen versuchen, die Kluft zwischen zwei verschiedenen Paradigmen zu überbrücken, was die Arten von Operationen einschränken kann, die sie ausdrücken können. Wenn Sie jedoch in Raw-SQL schreiben, können Sie alle Funktionen Ihrer Datenbank-Engine nutzen und komplexere Abfragen formulieren.

Nachteile der nativen Abfrage

Obwohl die native Abfrage einige eindeutige Stärken hat, ist sie nicht ohne Probleme.

Bei der Interaktion mit einer Datenbank aus einer Anwendung heraus, die einfaches SQL verwendet, müssen Sie die zugrunde liegende Datenstruktur verstehen, um gültige Abfragen erstellen zu können. Sie sind vollständig verantwortlich für die Übersetzung zwischen den Datentypen und Strukturen, die Ihre Anwendung verwendet, und den im Datenbanksystem verfügbaren Konstruktionen.

Eine andere Sache, die Sie bei der Arbeit mit rohem SQL beachten sollten, ist, dass es ganz Ihnen überlassen ist, die Sicherheit Ihrer Eingaben zu verwalten. Dies gilt insbesondere, wenn Sie Daten speichern, die von externen Benutzern bereitgestellt werden, wo speziell gestaltete Eingaben Ihre Datenbank dazu veranlassen könnten, Informationen preiszugeben, die Sie nicht zulassen wollten.

Diese Art von Exploit wird als SQL-Injection bezeichnet und ist ein potenzielles Problem, wenn Benutzereingaben den Datenbankstatus beeinflussen können. Höhere Abstraktionswerkzeuge bereinigen Benutzereingaben oft automatisch und helfen Ihnen, diese Art von Problemen zu vermeiden.

Das Arbeiten mit nativen Abfragesprachen bedeutet fast immer, Abfragen mit regulären Zeichenfolgen zu erstellen. Dies kann ein schmerzhafter Prozess sein, wenn Sie Eingaben maskieren und Zeichenfolgen miteinander verketten müssen, um eine gültige Abfrage zu erstellen. Ihre Datenbankoperationen können in viele Ebenen der String-Manipulation verwickelt werden, die ein hohes Potenzial zur versehentlichen Verstümmelung von Daten haben.

Native Abfragezusammenfassung

Obwohl wir in diesem Abschnitt hauptsächlich über SQL gesprochen haben, gelten die meisten Informationen hier gleichermaßen für jede native Datenbankabfragesprache. Zusammenfassend lässt sich sagen, dass rohes SQL oder die direkte Verwendung einer gleichwertigen Abfragesprache Sie den Abstraktionen, die von der Datenbank zum Speichern und Verwalten der Daten verwendet werden, am nächsten kommt, aber Sie dazu zwingt, all die schwere Arbeit der manuellen Verwaltung Ihrer Daten zu erledigen.

Datenverwaltung mit Abfrageerstellern

Ein alternativer Ansatz zur Verwendung von datenbanknativen Abfragesprachen wie SQL besteht darin, ein Tool oder eine Bibliothek namens Query Builder zu verwenden, um mit Ihrer Datenbank zu kommunizieren.

Was sind SQL-Abfrageersteller?

Ein SQL-Abfrage-Generator fügt eine Abstraktionsschicht über rohen datenbanknativen Abfragesprachen hinzu. Sie tun dies, indem sie Abfragemuster formalisieren und Methoden oder Funktionen bereitstellen, die Eingabebereinigungen hinzufügen und Elemente zur einfacheren Integration in Anwendungen automatisch maskieren.

Die von der Datenbankschicht unterstützten Strukturen und Aktionen sind bei der Verwendung von SQL-Abfragegeneratoren immer noch gut erkennbar. Auf diese Weise können Sie programmgesteuert mit Daten arbeiten und dennoch relativ nah an den Daten bleiben.

Normalerweise stellen Abfrage-Generatoren eine Schnittstelle bereit, die Methoden oder Funktionen verwendet, um einer Abfrage eine Bedingung hinzuzufügen. Durch die Verkettung von Methoden können Entwickler vollständige Datenbankabfragen aus diesen einzelnen "Klauseln" zusammenstellen.

Vorteile von SQL-Abfrageerstellern

Da Abfrage-Generatoren dieselben Konstruktionen (Methoden oder Funktionen) wie der Rest Ihrer Anwendung verwenden, finden Entwickler sie oft einfacher, sie langfristig zu verwalten als rohe Datenbankabfragen, die als Zeichenfolgen geschrieben sind. Es ist einfach, den Unterschied zwischen Operatoren und Daten zu erkennen, und es ist einfach, Abfragen in logische Blöcke zu zerlegen, die bestimmte Teile einer Abfrage behandeln.

Für einige Entwickler besteht ein weiterer Vorteil der Verwendung eines SQL-Abfragegenerators darin, dass die zugrunde liegende Abfragesprache nicht immer ausgeblendet wird. Obwohl die Operationen möglicherweise Methoden anstelle von Zeichenfolgen verwenden, kann dies ziemlich transparent sein, was es für diejenigen, die mit der Datenbank vertraut sind, einfacher macht, zu verstehen, was eine Operation bewirkt. Dies ist nicht immer der Fall, wenn höhere Abstraktionsebenen verwendet werden.

SQL-Abfragegeneratoren unterstützen häufig auch mehrere Daten-Backends und abstrahieren beispielsweise einige der subtilen Unterschiede in verschiedenen relationalen Datenbanken. Dadurch können Sie dieselben Tools für Projekte verwenden, die unterschiedliche Datenbanken verwenden. Es kann sogar die Migration zu einer neuen Datenbank etwas einfacher machen.

Nachteile von SQL-Abfrageerstellern

SQL-Abfragegeneratoren leiden unter einigen der gleichen Nachteile wie native Abfragesprachen.

Ein beliebter Kritikpunkt ist, dass SQL-Abfragegeneratoren immer noch verlangen, dass Sie die Strukturen und Fähigkeiten der Datenbank verstehen und berücksichtigen. Dies ist für einige Entwickler keine ausreichend nützliche Abstraktion. Das bedeutet, dass Sie zusätzlich zu der spezifischen Syntax und den Fähigkeiten des Abfragegenerators selbst über ein ziemlich gutes SQL-Verständnis verfügen müssen.

Darüber hinaus müssen Sie bei SQL-Abfragegeneratoren immer noch definieren, wie sich die abgerufenen Daten auf Ihre Anwendungsdaten beziehen. Es gibt keine automatische Synchronisierung zwischen Ihren In-Memory-Objekten und denen in der Datenbank.

Während Abfragegeneratoren häufig die Abfragesprache emulieren, mit der sie arbeiten sollen, kann die zusätzliche Abstraktionsebene dazu führen, dass manchmal bestimmte Operationen mit den bereitgestellten Methoden nicht möglich sind. Normalerweise gibt es einen "Raw"-Modus, um Abfragen direkt an das Backend zu senden und dabei die typische Schnittstelle des Abfragegenerators zu umgehen, aber das umgeht das Problem, anstatt es zu lösen.

Zusammenfassung der SQL-Abfrageersteller

Insgesamt bieten SQL-Abfragegeneratoren eine dünne Abstraktionsschicht, die speziell auf einige der wichtigsten Schwachpunkte bei der direkten Arbeit mit datenbanknativen Sprachen abzielt. SQL-Abfrage-Generatoren fungieren fast wie ein Templating-System für Abfragen, sodass Entwickler die Grenze zwischen der direkten Arbeit mit der Datenbank und dem Hinzufügen zusätzlicher Abstraktionsebenen überschreiten können.

Datenverwaltung mit ORMs

Eine Stufe weiter oben in der Abstraktionshierarchie sind ORMs. ORMs zielen im Allgemeinen auf eine vollständigere Abstraktion in der Hoffnung auf eine flüssigere Integration mit den Anwendungsdaten ab.

Was sind ORMs?

Objektrelationale Mapper oder ORMs sind Softwareteile, die für die Übersetzung zwischen den Datendarstellungen in relationalen Datenbanken und der Darstellung im Speicher, der bei der objektorientierten Programmierung (OOP) verwendet wird, vorgesehen sind. Das ORM bietet eine objektorientierte Schnittstelle zu Daten innerhalb der Datenbank und versucht, vertraute Programmierkonzepte zu verwenden und die Menge an Boilerplate-Code zu reduzieren, die erforderlich ist, um die Entwicklung zu beschleunigen.

Im Allgemeinen dienen ORMs als Abstraktionsschicht, die Entwicklern helfen soll, mit Datenbanken zu arbeiten, ohne das objektorientierte Paradigma drastisch zu ändern. Dies kann hilfreich sein, indem es die mentale Belastung reduziert, sich an die Besonderheiten des Speicherformats einer Datenbank anzupassen.

Insbesondere Objekte in der objektorientierten Programmierung neigen dazu, viele Zustände in sich zu codieren, und können durch Vererbung und andere OOP-Konzepte komplexe Beziehungen zu anderen Objekten haben. Diese Informationen zuverlässig in ein tabellenorientiertes relationales Paradigma abzubilden, ist oft nicht einfach und kann ein gutes Verständnis beider Systeme erfordern. ORMs versuchen, diese Belastung zu verringern, indem sie einige dieser Zuordnungen automatisieren und ausdrucksstarke Schnittstellen zu den Daten innerhalb des Systems bereitstellen.

Sind die Herausforderungen von ORMs spezifisch für die objektorientierte Programmierung? und relationale Datenbanken?

Per Definition sind ORMs speziell als Schnittstelle zwischen objektorientierten Anwendungssprachen und relationalen Datenbanken konzipiert. Der Versuch, die in Programmiersprachen verwendeten Datenstruktur-Abstraktionen und die von Datenbankspeichern verwendeten abzubilden und zu übersetzen, ist jedoch ein allgemeineres Problem, das immer dann auftreten kann, wenn Abstraktionen nicht sauber ausgerichtet sind.

Abhängig vom Programmierparadigma (objektorientiert, funktional, prozedural usw.) und dem Datenbanktyp (relational, Dokument, Schlüsselwert usw.) können unterschiedliche Abstraktionsgrade hilfreich sein. Oft bestimmt die Komplexität der Datenstrukturen innerhalb der Anwendung, wie einfach die Schnittstelle zum Datenspeicher ist.

Die objektorientierte Programmierung neigt dazu, viele Strukturen mit signifikanten Zuständen und Beziehungen zu erzeugen, die berücksichtigt werden müssen. Einige andere Programmierparadigmen sind expliziter darüber, wo der Zustand gespeichert und wie er verwaltet wird. Zum Beispiel erlauben rein funktionale Sprachen keinen veränderlichen Zustand, daher ist der Zustand oft eine Eingabe für Funktionen oder Objekte, die einen neuen Zustand ausgeben. Diese saubere Trennung von Daten und Aktionen sowie die Explizitheit von Zustandslebenszyklen können dazu beitragen, die Interaktion mit der Datenbank zu vereinfachen.

In beiden Fällen ist häufig die Option verfügbar, über eine Software, die zwischen zwei verschiedenen Darstellungen abbildet, eine Schnittstelle mit einer Datenbank herzustellen. Während ORMs also eine bestimmte Teilmenge davon mit einzigartigen Herausforderungen beschreiben, muss die Zuordnung zwischen Anwendungsspeicher und persistentem Speicher oft unabhängig von Details berücksichtigt werden.

Active record vs. Data Mapper ORMs

Unterschiedliche ORMs verwenden unterschiedliche Strategien, um zwischen Anwendungs- und Datenbankstrukturen abzubilden. Die beiden Hauptkategorien sind das aktive Aufzeichnungsmuster und das Datenzuordnungsmuster .

Das aktive Datensatzmuster versucht, die Daten der Datenbank innerhalb der Struktur von Objekten in Ihrem Code zu kapseln. Objekte enthalten Methoden zum Speichern, Aktualisieren oder Löschen aus der Datenbank, und Änderungen an Ihren Objekten sollen sich leicht in der Datenbank widerspiegeln. Im Allgemeinen stellt ein aktives Datensatzobjekt in Ihrer Anwendung einen Datensatz in einer Datenbank dar.

Active-Record-Implementierungen ermöglichen es Ihnen, Ihre Datenbank zu verwalten, indem Sie Klassen und Instanzen in Ihrem Code erstellen und verbinden. Da diese im Allgemeinen Klasseninstanzen direkt Datenbankeinträgen zuordnen, ist es einfach, sich vorzustellen, was sich in Ihrer Datenbank befindet, wenn Sie verstehen, welche Objekte in Ihrem Code verwendet werden.

Leider kann dies auch mit einigen großen Nachteilen einhergehen. Anwendungen sind in der Regel sehr eng mit der Datenbank gekoppelt, was bei der Migration auf eine neue Datenbank oder sogar beim Testen Ihres Codes zu Problemen führen kann. Ihr Code verlässt sich in der Regel auf die Datenbank, um Lücken zu füllen, die von Ihren Objekten ausgelagert wurden. Die „magische“ Übersetzung zwischen diesen beiden Domänen kann auch zu Leistungsproblemen führen, da das System versucht, komplexe Objekte nahtlos auf die zugrunde liegende Datenstruktur abzubilden.

Das Data-Mapper-Muster ist das andere gängige ORM-Muster. Wie das aktive Datensatzmuster versucht der Data Mapper, als unabhängige Ebene zwischen Ihrem Code und Ihrer Datenbank zu fungieren, die zwischen den beiden vermittelt. Anstatt zu versuchen, Objekte und Datenbankeinträge nahtlos zu integrieren, konzentriert es sich jedoch darauf, zu versuchen, sie zu entkoppeln und zwischen ihnen zu übersetzen, während jedes unabhängig existiert. Dies kann dabei helfen, Ihre Geschäftslogik von datenbankbezogenen Details zu trennen, die sich mit Zuordnungen, Darstellung, Serialisierung usw. befassen.

Anstatt also das ORM-System herausfinden zu lassen, wie die Objekte und die Datenbanktabellen zugeordnet werden sollen, ist der Entwickler für die explizite Zuordnung zwischen den beiden verantwortlich. Dies kann dazu beitragen, eine enge Kopplung und Operationen hinter den Kulissen zu vermeiden, was zu erheblich mehr Arbeit bei der Ermittlung geeigneter Mappings führt.

Vorteile von ORMs

ORMs sind aus vielen Gründen beliebt.

Sie helfen, die zugrunde liegende Datendomäne zu etwas zu abstrahieren, über das im Kontext Ihrer Anwendung leicht nachgedacht werden kann. Anstatt die Datenspeicherung als unabhängiges System zu betrachten, helfen Ihnen ORMs, als Erweiterung Ihrer aktuellen Arbeit auf Datensysteme zuzugreifen und diese zu verwalten. Dies kann Entwicklern dabei helfen, schneller an der Kerngeschäftslogik zu arbeiten, anstatt sich in den Nuancen ihrer Speicher-Backends zu verzetteln.

Ein weiterer Nebeneffekt davon ist, dass ORMs viele der Boilerplates entfernen, die für die Schnittstelle mit Datenbanken erforderlich sind. ORMs werden häufig mit Migrationstools geliefert, mit denen Sie Datenbankschemaänderungen basierend auf Änderungen in Ihrem Code verwalten können. Sie müssen nicht unbedingt das perfekte Datenbankschema im Voraus herausfinden, wenn Ihr ORM bei der Verwaltung von Änderungen an der Datenbankstruktur helfen kann. Ihre Anwendungs- und Datenbankänderungen sind oft identisch oder eng miteinander verwandt, was dazu beiträgt, Änderungen an Ihrer Datenbank nachzuverfolgen, während Sie Änderungen an Ihrem Code vornehmen.

Nachteile von ORMs

ORMs sind nicht ohne Fehler. In vielen Fällen ergeben sich diese aus denselben Entscheidungen, die ORMs nützlich machen.

Eines der grundlegenden Probleme mit ORMs ist der Versuch, die Details des Datenbank-Backends zu verbergen. Diese Verschleierung erleichtert die Arbeit mit ORMs in einfachen Fällen oder auf kleinen Zeitskalen, führt jedoch häufig zu Problemen, wenn die Komplexität zunimmt.

Die Abstraktion ist nie zu 100 % vollständig, und der Versuch, ein ORM zu verwenden, ohne die zugrunde liegende Abfragesprache oder Datenbankstruktur zu verstehen, führt oft zu problematischen Annahmen. Dies kann das Debugging und die Leistungsoptimierung erschweren oder unmöglich machen.

Das vielleicht bekannteste Problem bei der Arbeit mit ORMs ist die objektrelationale Impedanzfehlanpassung, ein Begriff, der verwendet wird, um die Schwierigkeit bei der Übersetzung zwischen objektorientierter Programmierung und dem von relationalen Datenbanken verwendeten relationalen Paradigma zu beschreiben. Die Inkompatibilitäten zwischen den von diesen beiden Technologiekategorien verwendeten Datenmodellen führen dazu, dass mit jeder Zunahme der Komplexität eine zusätzliche, unvollkommene Abstraktion erforderlich ist. Objekt-relationale Impedanz-Missanpassung wurde das Vietnam der Informatik genannt (in Anlehnung an den Vietnamkrieg), weil es dazu neigt, die Komplexität im Laufe der Zeit zu erhöhen und zu Situationen führt, in denen der Weg zum Erfolg oder zur Kursänderung schwierig oder unmöglich ist. P>

Im Allgemeinen sind ORMs langsamer als Alternativen, insbesondere bei komplexen Abfragen. ORMs generieren oft komplizierte Abfragen für relativ einfache Datenbankoperationen, weil sie allgemeine Muster verwenden, die flexibel genug sein müssen, um andere Fälle zu handhaben. Sich darauf zu verlassen, dass das ORM unter allen Umständen das Richtige tut, kann zu kostspieligen Fehlern führen, die im Vorfeld nur schwer aufgeholt werden können.

Zusammenfassung der ORMs

ORMs können nützliche Abstraktionen sein, die die Arbeit mit Datenbanken erheblich erleichtern. Sie können Ihnen helfen, schnell zu entwerfen und zu iterieren und die konzeptionellen Unterschiede zwischen der Anwendungslogik und den Datenbankstrukturen zu überbrücken. Viele dieser Vorteile wirken jedoch wie ein zweischneidiges Schwert. Sie können Sie daran hindern, Ihre Datenbanken zu verstehen, und können das Debuggen, Ändern von Paradigmen oder Erhöhen der Leistung erschweren.

Glossar

Bei der Arbeit mit Technologien, die eine Schnittstelle zwischen Datenbanken und Anwendungen bilden, stoßen Sie möglicherweise auf einige Begriffe, mit denen Sie nicht vertraut sind. In diesem Abschnitt gehen wir kurz auf einige der häufigsten Begriffe ein, auf die Sie stoßen könnten, von denen einige bereits früher in diesem Artikel behandelt wurden und andere nicht.

• Datenmapper: Ein Data Mapper ist ein Entwurfsmuster oder eine Software, die Programmierdatenstrukturen auf diejenigen abbildet, die in einer Datenbank gespeichert sind. Data Mapper versuchen, Änderungen zwischen den beiden Quellen zu synchronisieren und sie gleichzeitig unabhängig voneinander zu halten. Der Mapper selbst ist dafür verantwortlich, eine funktionierende Übersetzung aufrechtzuerhalten, was Entwicklern die Möglichkeit gibt, die Anwendungsdatenstrukturen zu iterieren, ohne sich um die Datenbankdarstellung zu kümmern.
• Datenbanktreiber: Ein Datenbanktreiber ist eine Software, die entwickelt wurde, um Verbindungen zwischen einer Anwendung und einer Datenbank zu kapseln und zu ermöglichen. Datenbanktreiber abstrahieren die Details auf niedriger Ebene, wie Verbindungen hergestellt und verwaltet werden, und stellen eine einheitliche, programmgesteuerte Schnittstelle zum Datenbanksystem bereit. Normalerweise stellen Datenbanktreiber die niedrigste Abstraktionsebene dar, die Entwickler verwenden, um mit Datenbanken zu interagieren, wobei Tools auf höherer Ebene auf den vom Treiber bereitgestellten Fähigkeiten aufbauen.
• Injektionsangriff: Ein Injection-Angriff ist ein Angriff, bei dem ein böswilliger Benutzer versucht, unerwünschte Datenbankoperationen mithilfe speziell gestalteter Eingaben in benutzerseitigen Anwendungsfeldern auszuführen. Dies wird häufig verwendet, um Daten abzurufen, auf die nicht zugegriffen werden sollte, oder um Informationen in der Datenbank zu löschen oder zu verstümmeln.
• ORM: ORMs oder objektrelationale Mapper sind Abstraktionsschichten, die zwischen den Datendarstellungen, die in relationalen Datenbanken verwendet werden, und der Darstellung im Speicher, der bei objektorientierter Programmierung verwendet wird, übersetzen. Das ORM bietet eine objektorientierte Schnittstelle zu Daten innerhalb der Datenbank und versucht, die Menge an Code zu reduzieren und vertraute Archetypen zu verwenden, um die Entwicklung zu beschleunigen.
• Objektbezogene Impedanzfehlanpassung: Die objektrelationale Impedanzfehlanpassung bezieht sich auf die Schwierigkeit der Übersetzung zwischen einer objektorientierten Anwendung und einer relationalen Datenbank. Da die Datenstrukturen erheblich variieren, kann es schwierig sein, die programmatischen Datenstrukturen originalgetreu und performant in das vom Speicher-Back-End verwendete Format zu ändern und zu transkribieren.
• Persistenz-Framework: Ein Persistenz-Framework ist eine Middleware-Abstraktionsschicht, die entwickelt wurde, um die Lücke zwischen Programmdaten und Datenbanken zu schließen. Persistenz-Frameworks können auch ORMs sein, wenn die von ihnen verwendete Abstraktion Objekte relationalen Entitäten zuordnet.
• Abfragegenerator: Ein Abfragegenerator ist eine Abstraktionsschicht, die Entwicklern hilft, auf Datenbanken zuzugreifen und diese zu steuern, indem sie eine kontrollierte Schnittstelle bereitstellt, die Funktionen für Benutzerfreundlichkeit, Sicherheit oder Flexibilität hinzufügt. Typischerweise sind Abfragegeneratoren relativ leichtgewichtig, konzentrieren sich auf die Erleichterung des Datenzugriffs und der Datendarstellung und versuchen nicht, die Daten in ein bestimmtes Programmierparadigma zu übersetzen.
• SQL: SQL oder strukturierte Abfragesprache ist eine domänenspezifische Sprache, die für die Verwaltung relationaler Datenbankverwaltungssysteme entwickelt wurde. Es kann verwendet werden, um Daten innerhalb einer Datenbank sowie deren Organisationsstrukturen abzufragen, zu definieren und zu manipulieren. SQL ist unter den relationalen Datenbanken allgegenwärtig.

Fazit

In diesem Artikel haben wir uns einige verschiedene Optionen für die Verbindung mit Ihrer Datenbank von Ihrer Anwendung aus angesehen. Wir haben die verschiedenen Abstraktionsebenen und die Flexibilität untersucht, die durch die Verwendung datenbanknativer Abfragesprachen wie SQL, die Verwendung eines Abfragegenerators zur sicheren Erstellung von Abfragen und ORMs zur Bereitstellung einer vollständigeren Abstraktionsebene geboten werden.

Jeder dieser Ansätze hat seinen Nutzen, und einige können für bestimmte Arten von Anwendungen besser geeignet sein als andere. Es ist wichtig, Ihre Anwendungsanforderungen, die Datenbankkenntnisse Ihrer Organisation und die Kosten der Abstraktionen (oder deren Fehlen), die Sie implementieren möchten, zu verstehen. Wenn Sie jeden Ansatz verstehen, haben Sie insgesamt die besten Chancen, die Option auszuwählen, die für Ihre Projekte am besten geeignet ist.