Datenbankabstraktion - wird sie übertrieben?

Nachdem ich zahlreichen Datenbankabstraktionsebenen ausgesetzt war, frage ich mich, worauf es bei jeder Bibliothek ankommt, die ihr eigenes Paradigma für den Datenzugriff entwickelt. Das Aufnehmen einer neuen DAL fühlt sich an, als würde ich eine neue Sprache noch einmal lernen, wenn ich normalerweise nur die Ebene davon überzeugen möchte, eine SQL-Abfrage auszugeben, die ich bereits in meinem Kopf geschrieben habe.

Und das, ohne die Lesbarkeit im Nachhinein anzugreifen:

# Exhibit A:  A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
    .inner_join(db.ips_x_users.user_id == db.users.id)
    .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)

# Exhibit B:  Another typical DAL
rows = db.ips_x_users
    .join(db.users, on=db.ips_x_users.user_id == db.users.id)
    .filter(db.ips_x_users.ip_addr == '127.0.0.1')
    .select(sort=~db.ips_x_users, limit=10)

# Exhibit C:  A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
             INNER JOIN users ON
                 (ips_x_users.user_id = users.id)
             WHERE ips_x_users.ip_addr = ip
             ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')

Was stimmt nicht mit der Standard-SQL-Syntax? Es wurde für einen bestimmten Zweck erstellt und passt wunderbar zu diesem Zweck. Vielleicht bin es nur ich, aber ich verstehe Snippet C viel leichter als die ersten beiden. Die umbenannten Schlüsselwörter und Syntaxtricks sind niedlich, aber IMO, wenn es darum geht, machen sie das Abrufen von Zeilen für den Codierer nicht einfacher.

Dies schien wahrscheinlich eine lange Angelegenheit zu sein, aber hier gibt es eine echte Frage. Da jede DAL eine neue DSL für Abfragen zu erfinden scheint, anstatt nur bewährtes SQL zu analysieren, muss es entweder Vorteile bei der Verwendung einer anderen Syntax geben oder Mängel in der Standard-SQL-Syntax, von denen ich nicht weiß, dass sie vorhanden sind. Kann jemand bitte darauf hinweisen, was ich hier übersehen habe?

Das grundlegendste Problem bei der Verwendung von SQL ist, dass SQL-Abfragen Zeichenfolgen sind, die aus einer anderen Sprache bestehen. Hier kommen SQL-Injections und andere Schwachstellen und WTFs her (Ihr Beispiel ist ziemlich schlecht gewählt, da Ihre Abfrage eigentlich keine Parameter enthält).

Das nächste Problem ist eigentlich eine Konsequenz: Wenn Sie nur SQL in Ihren Code geschrieben haben, kann der Compiler nichts dagegen tun. Fehler wie Tippfehler in Spaltennamen treten nur zur Laufzeit auf. Dies ist im Grunde, warum Sie nicht nur eine Zeichenfolgendarstellung Ihrer Abfrage in Ihrem Quellcode wollen, sondern etwas, das der Compiler statisch analysieren kann, um 95% aller Facepalm-Bugs zu verhindern.

Das letzte Problem tritt auf, wenn Sie versuchen, eine relationale Datenbank auf Ihre Sprachsemantik und Ihr Programmiermodell abzubilden: RDBMS passen nicht gut zu OOP (oder zum Abrufen von Navigationsdaten). Eigentlich ist das eine schreckliche Idee, diese beiden zu kombinieren, aber darum geht es bei allen objektorientierten DAL für SQL-Datenbanken (dh ORMs). Aber all diese Abstraktionsschichten sind zum Auslaufen verurteilt. Ich denke, das ist im Grunde der Grund, warum es so viele von ihnen gibt: Weil du mit ihnen arbeitest, siehst du, dass sie fehlerhaft sind, machst du dich daran, eine DAL zu schreiben, die es richtig macht und letztendlich scheitert.

Während die Probleme eins und zwei darauf hindeuten, DALs zu haben, die SQL loswerden, impliziert Problem drei, dass es keine einfache Lösung gibt, eine zu haben (zumindest für OOP), und es wird daher immer ein Meer von DALs mit unterschiedlichen Stärken und Einschränkungen geben. Am Ende können Sie nur einige sorgfältig auswählen und dabei bleiben.

Sie übersehen die offensichtliche Tatsache, dass nicht alle Datenbankplattformen dieselbe SQL-Syntax akzeptieren, sodass das Einbetten von SQL-Anweisungen in Ihre Anwendung nicht für jede Datenbankplattform funktioniert. Wenn Sie jemals mehrere Datenbankplattformen unterstützen müssen, müssen Sie die meisten (wenn nicht alle) dieser SQL-Anweisungen überdenken.

Ich habe das Gefühl, dass SQL die gleiche große Veränderung erlebt wie vor 10 Jahren. Es wird immer wieder versucht, manuelle Arbeit mit SQL zu eliminieren und auf eine höhere Abstraktionsebene zu bringen. Das gleiche geschah vor vielen Jahren mit Zeigern und manueller Speicherverwaltung.

Da die Arbeit gerade im Gange ist, werden Ihnen viele verschiedene Ansätze vorgeschlagen, ausprobiert, aufgegeben und integriert. Ich bin sicher, wir werden mehr davon sehen, bevor sich eine Art gemeinsamer Ansatz oder Industriestandard manifestiert.

Es gibt Ihnen sicherlich einen Vorteil, wenn Sie den Datenzugriffscode auf derselben Ebene und mit demselben Paradigma bearbeiten können, das Sie bei der Arbeit mit Ihrem Anwendungscode anwenden.

In wenigen Worten - Vereinfachung, Beweglichkeit, Schnelligkeit - das sind die Ziele.

Joel hatte vor 10 Jahren einen schönen Artikel geschrieben: Lassen Sie sich von Architektur-Astronauten nicht erschrecken

Ich denke, das ist genau der Fall. Ich habe die Abstraktionsebene in meinen eigenen Anwendungen verwendet, seit ich ein Muster gefunden habe, und es war einfach für mich, dies zu tun. Aber es war mein DAL, ich kannte jede einzelne Zeile im Quellcode => volle Kontrolle. Aber ich würde nicht empfehlen, dieses Framework für jemanden außerhalb meines Teams / meiner Projekte zu verwenden.

Wenn Sie so etwas verwenden, ist es wichtig zu wissen, wie es implementiert ist. Das bedeutet, dass Sie viel Zeit mit dem Erlernen der Bibliothek / des Tools verbringen sollten. Wenn Sie keine Zeit haben, es zu lernen, verwenden Sie es nicht. Auch wenn es von Anfang an sehr einfach aussieht.