Ich habe viel von Robert C. Martin gelesen / gesehen. Ich bin auf ihn gestoßen, als er sagte, SQL sei wegen Solid-State-Laufwerken unnötig. Wenn ich nach anderen Quellen suche, um dies zu sichern, erhalte ich eine Reihe von zufälligen Artikeln, in denen der Unterschied der SQL-Leistung zwischen Festplatten und Solid-State-Laufwerken beschrieben wird (was damit zusammenhängt, aber nicht das, was ich zu erforschen versuche).

Letztendlich verstehe ich nicht, worauf er abzielt. Sagt er, SQL durch No-SQL-Technologien zu ersetzen? Sagt er, Daten in Dateien in einem Dateisystem zu speichern? Oder möchte er nur, dass die Leute aufgrund von SQLi-Angriffen aufhören, SQL / Relationale Datenbanken zu verwenden? Ich fürchte, ich verpasse den Punkt, den er anstrebt.

Ich werde hier einige Links bereitstellen, damit Sie direkt aus seinen Gedanken lesen können:

1. Bobby Tische
2. Vortrag über saubere Architektur

Zunächst erklärt er, dass SQL vollständig aus dem System entfernt werden sollte.

Die Lösung. Die einzige Lösung. Ist es, SQL vollständig aus dem System zu eliminieren. Wenn es keine SQL-Engine gibt, kann es keine SQLi-Angriffe geben.

Und obwohl er über das Ersetzen von SQL durch eine API spricht, denke ich NICHT, dass er SQL hinter eine API stellen soll, weil er zuvor zitiert und weiter oben in diesem Artikel darauf hingewiesen wurde.

Frameworks behandeln das Problem nicht; ...

Randnotiz: Wenn ich SQL sage, bin ich mir ziemlich sicher, dass Robert die meisten relationalen Datenbanken meint. Vielleicht nicht alle, aber die meisten. Auf jeden Fall verwenden die meisten Leute SQL. damit...

Wenn SQL nicht zum Speichern von Daten verwendet wird, was sollen wir dann verwenden?

Bevor ich darauf antworte, sollte ich auch beachten. Robert betont, dass Solid-State-Laufwerke die Tools ändern sollten, die wir zum Speichern von Daten verwenden. Die Antwort von Søren D. Ptæus weist darauf hin.

Ich muss auch auf die Gruppe "Aber Datenintegrität" antworten. Nach weiteren Recherchen sollten wir Transaktionsdatenbanken wie datomic verwenden . Dann verwandelt sich CRUD in CR (Erstellen und Lesen) und SQL-Transaktionen verschwinden vollständig. Datenintegrität ist natürlich wichtig.

Ich kann keine Frage finden, die all dies umfasst. Ich suche nach Alternativen, die Roberts Richtlinien entsprechen. Datomic ist eins, aber ist es das? Welche anderen Optionen entsprechen diesen Richtlinien? Und funktionieren sie tatsächlich besser mit Solid-State-Laufwerken?

Bob Martin übertreibt deutlich, um seinen Standpunkt klarer zu machen. Aber worum geht es ihm?

Will er nur, dass die Leute aufgrund von SQLi-Angriffen aufhören, SQL / Relational Databases zu verwenden?

Meines Erachtens versucht Martin in diesem Blog-Post (Ihrem ersten Link) die Leute davon zu überzeugen, keine SQL-Datenbanken mehr zu verwenden, sondern relationale Datenbanken. Das sind zwei verschiedene Dinge .

SQL ist eine äußerst mächtige Sprache und bis zu einem gewissen Grad standardisiert. Es ermöglicht das Erstellen komplexer Abfragen und Befehle auf sehr kompakte, lesbare, verständliche und leicht zu erlernende Weise. Es hängt nicht von einer anderen Programmiersprache ab und ist daher für die meisten Anwendungsprogrammierer geeignet, unabhängig davon, ob sie Java, C, C ++, C #, Python, Ruby, JavaScript, Basic, Go, Perl, PHP oder etwas anderes bevorzugen.

Diese Leistung ist jedoch mit Kosten verbunden : Das Schreiben sicherer SQL-Abfragen / -Befehle ist schwieriger als das Schreiben unsicherer. Eine sichere API sollte es "standardmäßig" einfach machen, sichere Abfragen zu erstellen. Potenziell unsichere sollten mehr Mentalität oder zumindest mehr Tipparbeit erfordern. Das ist meiner Meinung nach der Grund, warum Martin gegen SQL in seiner jetzigen Form protestiert.

Das Problem ist nicht neu und es gibt sicherere APIs als Standard-SQL für den Zugriff auf eine relationale Datenbank. Beispielsweise versuchen alle mir bekannten OP-Mapper, eine solche API bereitzustellen (obwohl sie in der Regel für andere primäre Ziele entwickelt wurden). Statische SQL-Varianten erschweren die Erstellung dynamischer Abfragen mit nicht bereinigten Eingabedaten (und das ist keine neue Erfindung: Embedded SQL, das häufig statisches SQL verwendet, ist etwa 30 Jahre alt).

Leider sind mir keine APIs bekannt, die so flexibel, standardisiert, ausgereift, sprachunabhängig und ebenso leistungsfähig sind wie SQL, insbesondere dynamisches SQL. Aus diesem Grund habe ich einige Zweifel an Martins Vorschlag, "SQL nicht zu verwenden", um die genannten Probleme realistisch zu lösen. Lesen Sie seinen Artikel daher als Gedanken in die richtige Richtung und nicht als "Best Practice", der Sie ab morgen blind folgen können.

Bob Martins Meinung ist genau das; die Meinung eines Mannes.

Von einem Programmierer wird erwartet, dass er das von ihm geschriebene System gut genug versteht, um seine Sicherheit und Leistung angemessen zu berücksichtigen. Das bedeutet, dass Sie, wenn Sie mit einer SQL-Datenbank sprechen, das tun, was die Bobby Tables- Website vorschreibt: Sie bereinigen Ihre Eingabedaten. Dies bedeutet, dass Sie Ihre SQL-Datenbank auf einem Computer ablegen, der eine angemessene Leistung verspricht. Es gibt sehr bekannte und gut verstandene Wege, um diese Dinge zu tun, und obwohl sie keine absolute Sicherheit oder ideale Leistung garantieren, tut dies auch nichts anderes.

Die Behauptung, dass wir SQL nicht mehr brauchen, weil wir jetzt SSDs haben, ist nur spekulativ. SQL wurde nicht erfunden, weil es noch keine Hochgeschwindigkeitsfestplatten gab. Es wurde erfunden, weil wir eine branchenübliche Methode zum Ausdrücken von Datenabrufkonzepten benötigten. Relationale Datenbanksysteme haben neben Geschwindigkeit und Sicherheit viele andere Eigenschaften, die sie ideal für den Geschäftsbetrieb machen. insbesondere ACID . Datenintegrität ist mindestens so wichtig wie Geschwindigkeit oder Sicherheit. Wenn Sie sie nicht haben, wozu sollten Sie dann fehlerhafte Daten sichern oder sie so schnell wie möglich abrufen?

Bevor Sie die Hysterie eines Mannes als Evangelium betrachten, sollten Sie sich mit der Anwendungs- und Systemsicherheit sowie der Leistung nach eigenen Maßstäben vertraut machen, und nicht durch das Lesen von zufälligen Internetartikeln. Sicherheit, Leistung und robustes Systemdesign bieten viel mehr als nur "Vermeiden Sie diese Technologie".

Wir verbieten keine Küchenmesser, weil es ein paar Unglücklichen gelingt, sich versehentlich die Finger zu schneiden.

Was sagt er eigentlich?

Sagt er, SQL durch No-SQL-Technologien zu ersetzen?

TL; DR: Ja (Art)

In einem neueren Vortrag als dem, zu dem Sie im Grunde genommen einen Link erstellt haben, sagt er: "Die Datenbank ist ein Detail. Warum haben wir Datenbanken?" .

Er behauptet, die Datenbank sollte den Datenzugriff von sich drehenden Datenträgern erleichtern, aber in [...] Zukunft wird es dank der neuen Technologie und des von ihm als "persistent RAM" bezeichneten Datenträgers keine Datenträger mehr geben Speichern Sie Daten mithilfe der Strukturen, die Programmierer verwenden, z. B. Hashtabellen oder Bäume.

Er geht weiter davon aus, dass relationale Datenbanken insgesamt aufgrund ihrer neuen Konkurrenz größtenteils verschwinden werden:

Wenn ich Oracle wäre, wäre ich ziemlich verängstigt, weil der Grund für meine Existenz unter mir verschwindet. [...] Der Grund für die Existenz der Datenbank verschwindet.

Es wird wahrscheinlich einige relationale Tabellen geben, die überleben, aber jetzt gibt es eine gesunde Konkurrenz .

Also nein, für ihn geht es nicht nur um SQL-Injection, obwohl er der Meinung ist , dass SQL in dieser Hinsicht von Natur aus fehlerhaft ist .

Anmerkung des Verfassers:

Die Aussagen in diesem Beitrag sind nur Anführungszeichen, um die Meinung von Robert C. Martin zu diesem Thema zu verstehen und geben nicht die Meinung des Autors wieder. Für eine differenziertere Sichtweise siehe die Antwort von Robert Harvey .

SQL ist ein Detail. Detailkenntnisse sollten sich nicht verbreiten.

Da SQL an immer mehr Stellen in Ihrem Code verwendet wird, hängt Ihr Code immer mehr davon ab.

Wenn Sie mehr und mehr SQL-Tricks lernen, lösen Sie immer mehr Probleme mit SQL. Das bedeutet, dass der Wechsel zu einer anderen API zum Fortbestehen mehr als nur das Übersetzen umfasst. Sie müssen Probleme lösen, die Sie nicht erkannt haben.

Sie laufen darauf hinaus, zwischen Datenbanken zu wechseln. Man bietet die Funktion 5 für ausgefallene Whizzbangs an, so dass Sie sie an einer Reihe von Stellen nur verwenden, um herauszufinden, ob die Funktion 5 für ausgefallene Whizzbangs proprietär ist, und jetzt haben Sie ein Lizenzproblem, das eine Menge Geld kosten wird. Sie arbeiten also viel an der Stelle, an der Sie Feature 5 verwendet haben, und lösen das Problem selbst, um später herauszufinden, dass Sie auch Feature 3 von Whizzbang verwenden.

Eines der Dinge, die Java so portabel machen, ist, dass bestimmte Funktionen der CPU einfach nicht verfügbar sind. Wenn sie verfügbar wären, würde ich sie benutzen. Und plötzlich gibt es CPUs, auf denen mein Java-Code nicht mehr funktioniert, weil sie nicht über diese Funktionen verfügen. Das Gleiche gilt für Datenbankfunktionen.

Es ist alles zu einfach, seine Unabhängigkeit zu opfern, ohne es zu merken. SQL ist eine Wahl, die nicht selbstverständlich ist. Wenn Sie sich für die Verwendung von SQL entscheiden, müssen Sie die Entscheidung an einem Ort treffen. Machen Sie es auf eine Weise, die ungemacht sein kann.

Die Tatsache, dass SQL Sicherheitsprobleme hat und wir auf persistente Speichermodelle umsteigen, bedeutet nicht, dass SQL zum Scheitern verurteilt ist. Es fährt gerade den Punkt nach Hause, dass es eine Wahl ist. Wenn Sie das Recht behalten möchten, diese Wahl zu treffen, müssen Sie die Arbeit erledigen.

Es kann erwähnenswert sein, dass die Datenbankbewegung der 80er Jahre und Onkel Bob eine ziemlich üble Vergangenheit haben. Er hatte all seine Probleme mit einem Flat-File-System gelöst, als das Management einen Datenbankadministrator in sein Leben zwang. Dieses Ereignis brachte ihn in seine herausragende Karriere als Berater. (Er erzählt diese Geschichte in einem seiner frühen sauberen Bücher, vergiss was). Er weiß, wie man Probleme ohne DBs löst und hat wenig Geduld für diejenigen, die sich so verhalten, als wären sie eine Selbstverständlichkeit.

Er erzählt auch eine Geschichte, in der es darum geht, das Hinzufügen einer Datenbank zu einer Anwendung bis zur letzten Minute zu verschieben, wenn ein Kunde dies wünscht, und es an einem Tag als optionale Funktion hinzuzufügen. Ich vermute, er sieht, wie die meisten von uns DBs als Sucht benutzen. Er versucht uns zu zeigen, wie wir die Gewohnheit ablegen können.

Das Zitat aus Ihrem ersten Zitat ist (Hervorhebung von mir),

Die Lösung. Die einzige Lösung. Ist es , SQL vollständig aus dem System zu eliminieren . Wenn es keine SQL-Engine gibt, kann es keine SQLi-Angriffe geben.

Was würde SQL ersetzen? Eine API natürlich! Und NICHT eine API, die eine Textsprache verwendet. Stattdessen greift eine API, die einen geeigneten Satz von Datenstrukturen und Funktionsaufrufen verwendet, auf die erforderlichen Daten zu.

Es wird dagegen protestiert, dass Anwendungsprogrammierer SQL verwenden.

Die vorgeschlagene Lösung besteht darin, sie stattdessen eine API verwenden zu lassen: Dies ist kein SQL-Code und erlaubt keine Injektion.

Beispiele für solche APIs könnten lauten:

• http://bobby-tables.com/csharp schlägt vor, dass C # -Programmierer die ADO.NET-API verwenden können.

  Das ist nicht ein perfektes Beispiel , weil ADO.NET eine breit oder tief (dh mächtig oder für allgemeine Zwecke) API, die auch seine Benutzer zur Eingabe roh (oder roh-ish) SQL ermöglicht.

• Einige SQL-Entwickler oder Datenbankadministratoren empfehlen, eine Datenbank so zu konfigurieren, dass nur über (eine begrenzte Anzahl von fachmännisch geschriebenen) gespeicherten Prozeduren auf sie zugegriffen werden kann und dass Anwendungsentwickler keine eigenen (gefährlichen) SQL-Abfragen schreiben dürfen

• Eine andere Möglichkeit, "SQL aus dem System zu entfernen", besteht darin, die Datenbank (die SQL verfügbar macht) auf einem anderen System zu platzieren, auf das über eine REST-API oder ähnliches zugegriffen wird.

Daher kann IMO, die Gesamtlösung oder das System weiterhin eine Datenbank verwenden (insbesondere, wenn eine Datenbank-Engine nützliche ACID-Eigenschaften implementiert und gut skaliert, ist es möglicherweise töricht, zu versuchen, auf eine zu verzichten, oder zu schreiben eine anwendungsspezifische).

Die Anforderungen des Rants sind erfüllt, wenn die SQL-API der Datenbank hinter einer anderen API (z. B. ADO, möglicherweise ein ORM, ein Webdienst oder was auch immer) vor den Anwendungsentwicklern verborgen ist.

Allgemeiner denke ich, dass es bedeutet, eine anwendungsspezifische DAL (eine "Datenzugriffsschicht" oder eine "Datenbankabstraktionsschicht") zu haben. Eine DAL isoliert die Anwendung von Einzelheiten darüber, wie und wo die Daten gespeichert und / oder abgerufen werden. Die DAL kann unter Verwendung einer SQL-Datenbank implementiert werden oder nicht.

Jeder scheint diese Frage aus Sicherheitsgründen oder mit einem SQL-Objektiv zu beantworten.

Ich habe einen Vortrag von Robert Martin gesehen, in dem er erzählt, dass wir als Programmierer viele verschiedene Datenstrukturen verwenden, die für unsere spezifischen Programme optimal sind. Anstatt alle Daten universell in einer Tabellenstruktur zu speichern, sollten wir unsere Daten in Hash-Tabellen, Bäumen usw. speichern, damit wir die Daten erfassen und direkt in das Programm springen können.

Ich interpretierte seine Botschaft nur so, dass wir unsere gegenwärtigen Annahmen über dauerhaften Speicher für einen Moment verwerfen sollten, um andere zukünftige Möglichkeiten als das uralte SQL-Tabellenformat in Betracht zu ziehen. SSD ist eine in Frage kommende Lösung, aber nicht die einzige.

Eigentlich soll er Datenbanken und SQL nicht verwenden - ziemlich explizit. Die erste Referenz ist ein bekanntes Thema, die zweite Referenz klingt wie ein Schimpfen. Ich interpretiere es jedoch so, dass es einen guten Grund gibt, Datenbanken und nicht SQL zu verwenden. Aus meiner Sicht ist dies nicht einmal eine vernünftige Empfehlung.

Leider ist das Beispiel, das er verwendet, ein bekanntes Beispiel mit einer bekannten Lösung, auf die er dann hinweist. Es kommt normalerweise vor, wenn ein Programmierer nicht merkt, was er tut. Zum Beispiel Strings erstellen, die SQL enthalten wie:

    my $sql="select a from b where a=$ui_val;";
    prepare($sql)
    execute($sql)

im Gegensatz zu

    my $sql="select a from b where a=?;";
    prepare($sql)
    execute($sql,$ui_val);

Dies ist ein DBI-Perl-ähnliches Beispiel für den Ruby-on-Rails-Code. Der Schienencode, den er bereitstellt, ist leicht zwischen dem sicheren und dem unsicheren zu verwechseln. Wie viele ORMs verbirgt sich das, worunter sich SQL befindet, und so oft haben Sie es mit einer Schnittstelle zu tun, die die SQL für Sie erstellt und ausführt. Klingt das nicht fast so, als würde eine API für Sie tun?

Meine Interpretation des ersten Verweises ist, dass er vorschlägt, dass wir ein bekanntes Problem ersetzen sollten, das eine bekannte Lösung hat.

Es ist auch bedauerlich, dass er nicht erwähnt, dass, wenn dies richtig gemacht wird, Code einfacher zu schreiben und besser lesbar ist. Wenn es jedoch gut gemacht wird, ist es möglicherweise schwieriger zu schreiben und weniger lesbar. Darüber hinaus erwähnt er nicht, dass SQL wirklich sehr einfach zu lesen ist und das tut, was man normalerweise erwarten würde.

Er hat teilweise recht, letztendlich werden wir einen unendlich großen und schnellen Speicher und einen unendlich schnellen Prozessor haben. Bis wir uns von der aktuellen Physik verabschieden, die das Rechnen einschränkt, ist er nicht korrekt.

Ja, rotierende Festplatten gehören der Vergangenheit an, und wir verwenden jetzt SSDs. Festplatten arbeiten mit ca. 10 Millisekunden pro Datenübertragung, SSDs mit einer Datenzugriffszeit von ca. 0,5 Millisekunden (500 Mikrosekunden). RAM liegt in der Größenordnung von 100 Nanosekunden, Prozessoren arbeiten in der Größenordnung von 100 Pikosekunden. Aus diesem Grund brauchen wir Datenbanken. Datenbanken verwalten die Datenübertragung zwischen sich drehenden Festplatten oder SSDs mit Hauptspeicher. Die Einführung von SSDs hat die Notwendigkeit von Datenbanken nicht beseitigt.

Antworten

will er nur, dass die Leute aufgrund von SQLi-Angriffen die Verwendung von SQL / Relational Databases einstellen?

Der 'Bobby Tables'-Artikel scheint darauf hinzudeuten, dass dies ein Grund ist, SQL nicht zu verwenden:

Die Lösung. Die einzige Lösung. Ist es, SQL vollständig aus dem System zu eliminieren. Wenn es keine SQL-Engine gibt, kann es keine SQLi-Angriffe geben.

Er könnte andere Gründe haben, die er anderswo bespricht. Ich würde es nicht wissen, weil ich nicht wirklich viel von seinen Sachen lese.

Abschweifung

Dieser Teil ist keine wirkliche Antwort, aber ich denke, die Frage nach dem Wert von SQL ist weitaus interessanter (wie anscheinend auch andere).

Ich habe viel Erfahrung mit SQL und ich denke, ich habe ein gutes Verständnis für seine Stärken und Schwächen. Mein persönliches Gefühl ist, dass es überbeansprucht und missbraucht wurde, aber die Idee, dass wir es niemals benutzen sollten, ist irgendwie albern. Die Vorstellung, dass wir "SQL immer" oder "SQL nie" wählen müssen, ist eine falsche Zweiteilung.

Was SQL-Injection als Argument für die Nichtverwendung von SQL anbelangt, ist das lächerlich. Dies ist ein gut verstandenes Problem mit einer ziemlich einfachen Lösung. Das Problem mit diesem Argument ist, dass SQLi nicht die einzige Schwachstelle ist, die existiert. Wenn Sie der Meinung sind, dass Sie durch die Verwendung von JSON-APIs sicher sind, werden Sie eine große Überraschung erleben.

Ich denke, jeder Entwickler sollte dieses Video mit dem Titel "Freitag, der 13.: JSON angreifen - Alvaro Muñoz & Oleksandr Mirosh - AppSecUSA 2017" ansehen.

Wenn Sie nicht die Zeit oder die Neigung haben, dies zu beobachten, sehen Sie sich Folgendes an: Viele JSON-Deserialisierungsbibliotheken weisen Sicherheitsanfälligkeiten in Bezug auf die Codeausführung von Remotestandorten aus auf. Wenn Sie XML verwenden, müssen Sie sich noch mehr Sorgen machen. Wenn Sie SQL aus Ihrer Architektur verbannen, wird Ihr System nicht sicherer.

Ich möchte nur eine kurze Aussage ansprechen:

Oder möchte er nur, dass die Leute aufgrund von SQLi-Angriffen aufhören, SQL / Relationale Datenbanken zu verwenden?

Nein, das ist eine falsche Annahme. Wir können nicht sagen, dass wir aufhören müssen, Autos zu benutzen, weil sie für Menschen verantwortlich sind, die bei Autounfällen sterben. Ebenso sind SQL- / relationale Datenbanken (oder in diesem Zusammenhang auch andere Elemente wie RDBMS) nicht für schädliche SQL-Nutzdaten verantwortlich, die ein Angreifer in Ihrer Webanwendung ausführen kann. Ich bin mir sicher, dass der Autor das nicht so gemeint hat, denn für diesen Zweck gibt es ein ganzes SQL Injection Prevention Cheat Sheet .

Martins Problem scheint darin zu liegen, dass Programmierer dynamisches SQL direkt aus Benutzereingaben erstellen (verzeihen Sie, ich bin hauptsächlich ein C- und C ++ - Programmierer):

sprintf( query, "select foo from bar where %s;", user_input );

Das ist absolut ein Rezept für Sodbrennen (daher der Bobby Tables Strip). Jeder Programmierer, der Code wie diesen in ein Produktionssystem einfügt, verdient einen Paddel.

Sie können das Problem durch die Verwendung von vorbereiteten Anweisungen und die ordnungsgemäße Bereinigung Ihrer Eingaben mindern (wenn nicht sogar ganz beseitigen). Wenn Sie die SQL hinter einer API verstecken können, so dass Programmierer nicht direkt Abfragezeichenfolgen erstellen, umso besser (was Teil dessen ist, was Martin befürwortet).

Aber um SQL vollständig loszuwerden, halte ich das nicht für praktisch oder wünschenswert. Relationale Modelle sind nützlich , deshalb gibt es sie in erster Linie, und SQL ist wahrscheinlich die beste Schnittstelle für die Arbeit mit relationalen Modellen.

Wie immer geht es darum, das richtige Werkzeug für den Job zu verwenden. Wenn Ihre Warenkorb-App kein vollständiges relationales Modell benötigt, verwenden Sie kein relationales Modell (dh, Sie müssen kein SQL verwenden). Wenn Sie ein relationales Modell benötigen, werden Sie mit ziemlicher Sicherheit mit SQL arbeiten.

Die beiden Quellen, die Sie verknüpfen, übermitteln unterschiedliche Botschaften:

Der Blogbeitrag besagt, dass die Datenzugriffslogik zur Laufzeit nicht als Text existieren sollte, damit sie nicht mit nicht vertrauenswürdigen Benutzereingaben gemischt wird. Das heißt, der Blog-Beitrag verurteilt das Schreiben von Abfragen durch Verketten von Zeichenfolgen.

Die Vorlesung ist anders. Der erste Unterschied ist der Ton: Die Vorlesung spekuliert und hinterfragt, verurteilt aber nicht. Er sagt nicht, dass Datenbanken böse sind, sondern fordert uns auf, uns eine Datenbank ohne Persistenz vorzustellen. Er argumentiert, dass sich in den 30 Jahren seit der Verbreitung relationaler Datenbanken viele Dinge geändert haben, und hebt zwei hervor, die sich möglicherweise auf unsere Wahl der Persistenztechnologie auswirken könnten:

• Die Lagerfläche hat sich um den Faktor 1 Million vergrößert - zu vergleichbaren Preisen! Infolgedessen ist es weniger notwendig, Speicherplatz zu sparen, und insbesondere ist es nicht länger erforderlich, ihn zu löschen. Durch die Verwendung von Nur-Anhängen-Speicher kann die Parallelitätskontrolle vereinfacht werden, da Lesesperren nicht erforderlich sind. Dies kann die Notwendigkeit von Transaktionen vermeiden.
• Die Zugriffszeiten sind gesunken, da die meisten Datensätze jetzt in den Arbeitsspeicher passen, was die Leselatenz massiv verringert.

Verändern diese veränderten Umstände die optimale Persistenztechnologie? Interessanterweise sagt Onkel Bob das nicht - vermutlich, weil er der Meinung ist, dass keine Antwort für alle Programme richtig wäre. Deshalb warnt er uns, unsere Wahl der Persistenztechnologie als Detail zu behandeln, anstatt sie in Steintafeln zu verwahren und sie als erhaltene Weisheit an unsere Kollegen weiterzugeben.

Gibt es Alternativen?

Das Schreiben einer Datenzugriffslogik ohne Zeichenfolgen ist durchaus möglich. In Java können Sie QueryDSL verwenden , bei dem Abfragen mithilfe einer typsicheren, fließenden API beschrieben werden, die aus Ihrem Datenbankschema generiert wurde. Eine solche Abfrage könnte folgendermaßen aussehen:

JPAQuery<?> query = new JPAQuery<Void>(entityManager);
Customer bob = query.select(customer)
  .from(customer)
  .where(customer.firstName.eq("Bob"))
  .fetchOne();

Wie Sie sehen, wird die Abfragelogik nicht als Zeichenfolge ausgedrückt, wodurch die vertrauenswürdige Struktur der Abfrage deutlich von den nicht vertrauenswürdigen Parametern getrennt wird (und QueryDSL schließt die Parameter natürlich nie in den Abfragetext ein, sondern verwendet vorbereitete Anweisungen, um die Abfrage zu trennen für seine Parameter auf JDBC-Ebene). Um SQL-Injection mit QueryDSL zu erreichen, müssten Sie Ihren eigenen Parser schreiben, um einen String zu analysieren und in einen Syntaxbaum zu übersetzen, und selbst wenn Sie dies tun, würden Sie wahrscheinlich keine Unterstützung für böse Dinge wie hinzufügen select ... into file. Kurz gesagt, QueryDSL macht SQL-Injection unmöglich, verbessert die Produktivität der Programmierer und erhöht die Refactoring-Sicherheit. Verhindert das größte Risiko für die Sicherheit von Webanwendungen, das lange genug besteht, um laufende Gags hervorzurufenund die Produktivität der Entwickler gesteigert? Ich wage zu sagen, dass Sie es falsch machen, wenn Sie immer noch Abfragen als Zeichenfolgen schreiben.

Was Alternativen zu relationalen Datenbanken angeht, ist es merkwürdig zu wissen, dass die Mehrversions- Parallelitätssteuerung von postgres genau diese Art von Datenstruktur ist, von der Onkel Bob spricht, obwohl er wahrscheinlich mehr an Event-Stores und das Event-Sourcing dachte Muster im Allgemeinen, das auch gut zu dem Gedanken passt, den aktuellen Status im RAM beizubehalten.