Warum keine Liebe zu SQL? [geschlossen]

Ich habe in letzter Zeit viel gehört, dass SQL eine schreckliche Sprache ist, und es scheint, dass jedes Framework unter der Sonne mit einer Datenbankabstraktionsschicht vorinstalliert ist.

Nach meiner Erfahrung ist SQL jedoch häufig die viel einfachere, vielseitigere und programmiererfreundlichere Methode zur Verwaltung der Dateneingabe und -ausgabe. Jede Abstraktionsschicht, die ich verwendet habe, scheint ein ausgesprochen begrenzter Ansatz ohne wirklichen Nutzen zu sein.

Was macht SQL so schrecklich und warum sind Datenbankabstraktionsschichten wertvoll?

Dies ist teilweise subjektiv. Das ist also meine Meinung:

SQL hat einen pseudo-natürlichen Sprachstil . Die Erfinder glaubten, dass sie eine Sprache wie Englisch erstellen können und dass Datenbankabfragen sehr einfach sein werden. Ein schrecklicher Fehler. SQL ist nur in trivialen Fällen schwer zu verstehen.

SQL ist deklarativ. Sie können der Datenbank nicht sagen, wie sie Dinge tun soll, nur was Sie als Ergebnis wollen. Dies wäre perfekt und sehr leistungsfähig - wenn Sie sich nicht um die Leistung kümmern müssten. Am Ende schreiben Sie SQL - lesen Ausführungspläne - formulieren SQL neu, um den Ausführungsplan zu beeinflussen, und Sie fragen sich, warum Sie den Ausführungsplan nicht selbst schreiben können .

Ein weiteres Problem der deklarativen Sprache besteht darin, dass einige Probleme auf zwingende Weise leichter zu lösen sind. Sie schreiben es also entweder in einer anderen Sprache (Sie benötigen Standard-SQL und wahrscheinlich eine Datenzugriffsschicht) oder verwenden herstellerspezifische Spracherweiterungen, beispielsweise durch Schreiben gespeicherter Prozeduren und dergleichen. Wenn Sie dies tun, werden Sie wahrscheinlich feststellen, dass Sie eine der schlechtesten Sprachen verwenden, die Sie jemals gesehen haben - weil sie nie für die Verwendung als zwingende Sprache konzipiert wurde.

SQL ist sehr alt . SQL wurde standardisiert, aber zu spät haben viele Anbieter bereits ihre Spracherweiterungen entwickelt. So endete SQL in Dutzenden von Dialekten. Aus diesem Grund sind Anwendungen nicht portabel und ein Grund für eine DB-Abstraktionsschicht.

Aber es ist wahr - es gibt keine realisierbaren Alternativen. Daher werden wir alle in den nächsten Jahren SQL verwenden.

Abgesehen von allem, was gesagt wurde, muss eine Technologie nicht schlecht sein, um eine Abstraktionsschicht wertvoll zu machen .

Wenn Sie ein sehr einfaches Skript oder eine Anwendung ausführen, können Sie es sich leisten, SQL-Aufrufe in Ihrem Code zu mischen, wo immer Sie möchten. Wenn Sie jedoch ein komplexes System ausführen, empfiehlt es sich, die Datenbankaufrufe in separaten Modulen zu isolieren, um Ihren SQL-Code zu isolieren. Es verbessert die Lesbarkeit, Wartbarkeit und Testbarkeit Ihres Codes. Sie können Ihr System schnell an Änderungen im Datenbankmodell anpassen, ohne alle wichtigen Dinge usw. aufzulösen.

SQL ist großartig. Abstraktion Schichten darüber macht es noch größer!

Ein Punkt der Abstraktionsschichten ist die Tatsache, dass SQL-Implementierungen in der Regel mehr oder weniger inkompatibel sind, da der Standard leicht mehrdeutig ist und die meisten Anbieter dort ihre eigenen (nicht standardmäßigen) Extras hinzugefügt haben. Das heißt, SQL, das für eine MySQL-Datenbank geschrieben wurde, funktioniert möglicherweise nicht ganz ähnlich wie beispielsweise eine Oracle-Datenbank - selbst wenn dies "sollte".

Ich stimme jedoch zu, dass SQL viel besser ist als die meisten Abstraktionsschichten da draußen. Es ist nicht die Schuld von SQL, dass es für Dinge verwendet wird, für die es nicht entwickelt wurde.

SQL wird aus verschiedenen Quellen schlecht geredet:

• Programmierer, die mit nichts anderem als einer zwingenden Sprache vertraut sind.
• Berater, die täglich mit vielen inkompatiblen SQL-basierten Produkten zu tun haben
• Nichtrelationale Datenbankanbieter, die versuchen, den Würgegriff relationaler Datenbankanbieter auf dem Markt zu brechen
• Experten für relationale Datenbanken wie Chris Date, die aktuelle Implementierungen von SQL als unzureichend ansehen

Wenn Sie sich an ein DBMS-Produkt halten, stimme ich definitiv zu, dass SQL-DBs vielseitiger und von höherer Qualität sind als ihre Konkurrenz, zumindest bis Sie eine Skalierbarkeitsbarriere erreichen, die dem Modell eigen ist. Aber versuchen Sie wirklich, das nächste Twitter zu schreiben, oder versuchen Sie nur, einige Buchhaltungsdaten organisiert und konsistent zu halten?

Kritik an SQL ist oft ein Argument für Kritik an RDBMS. Kritiker von RDBMS scheinen nicht zu verstehen, dass sie eine große Klasse von Computerproblemen recht gut lösen und dass sie hier sind, um unser Leben leichter und nicht schwerer zu machen.

Wenn sie es ernst meinten, SQL selbst zu kritisieren, würden sie Bemühungen wie Tutorial D und Dataphor unterstützen.

Es ist nicht so schrecklich. Es ist ein unglücklicher Trend in dieser Branche, die bisherige zuverlässige Technologie zu verwerfen, wenn ein neues "Paradigma" herauskommt. Letztendlich verwenden diese Frameworks höchstwahrscheinlich SQL, um mit der Datenbank zu kommunizieren. Wie kann es also so schlimm sein? Das heißt, eine "Standard" -Abstraktionsschicht bedeutet, dass sich ein Entwickler auf den Anwendungscode und nicht auf den SQL-Code konzentrieren kann. Ohne eine solche Standardebene würden Sie wahrscheinlich jedes Mal, wenn Sie ein System entwickeln, eine leichte schreiben, was eine Verschwendung von Aufwand ist.

SQL wurde für die Verwaltung und Abfrage von SET-basierten Daten entwickelt. Es wird oft verwendet, um mehr zu tun, und Randfälle führen manchmal zu Frustration.

Die tatsächliche Verwendung von SQL kann durch das Basisdatenbankdesign SO beeinflusst werden, dass SQL möglicherweise nicht das Problem ist, das Design jedoch - und wenn Sie den mit einem schlechten Design verbundenen Legacy-Code einwerfen, sind Änderungen wirkungsvoller und kostenintensiver zu implementieren ( niemand geht gerne zurück und "repariert" Dinge, die "funktionieren" und Ziele erreichen)

Tischler können Nägel mit Hämmern schlagen, Schnittholz mit Sägen und glatte Bretter mit Flugzeugen. Es ist möglich, mit Hämmern und Flugzeugen zu "sägen", aber verdammt, es ist frustrierend.

Ich werde nicht sagen, dass es schrecklich ist. Es ist für einige Aufgaben ungeeignet. Zum Beispiel: Sie können mit SQL keinen guten Prozedurcode schreiben. Ich war einmal gezwungen, mit Set-Manipulation mit SQL zu arbeiten. Ich habe ein ganzes Wochenende gebraucht, um das herauszufinden.

SQL wurde für die relationale Algebra entwickelt - dort sollte es verwendet werden.

Ich habe in letzter Zeit viel gehört, dass SQL eine schreckliche Sprache ist, und es scheint, dass jedes Framework unter der Sonne mit einer Datenbankabstraktionsschicht vorinstalliert ist.

Beachten Sie, dass diese Ebenen nur ihre eigenen Inhalte in konvertieren SQL. Für die meisten Datenbankanbieter SQList dies die einzige Möglichkeit, mit der Engine zu kommunizieren.

Nach meiner Erfahrung ist SQL jedoch häufig die viel einfachere, vielseitigere und programmiererfreundlichere Methode zur Verwaltung der Dateneingabe und -ausgabe. Jede Abstraktionsschicht, die ich verwendet habe, scheint ein ausgesprochen begrenzter Ansatz ohne wirklichen Nutzen zu sein.

… Grund, aus dem ich gerade oben beschrieben habe.

Die Datenbankebenen fügen nichts hinzu, sie beschränken Sie nur. Sie machen die Abfragen umstritten einfacher, aber niemals effizienter.

Per Definition gibt es in den Datenbankebenen nichts, was nicht vorhanden ist SQL.

Was macht SQLso schrecklich und warum sind Datenbankabstraktionsschichten wertvoll?

SQL ist eine schöne Sprache, aber es braucht ein wenig Gehirnarbeit, um damit zu arbeiten.

Theoretisch SQList deklarativ, das heißt, Sie deklarieren, was Sie erhalten möchten, und der Motor liefert es auf die schnellstmögliche Weise.

In der Praxis gibt es viele Möglichkeiten, eine korrekte Abfrage zu formulieren (dh die Abfrage, die korrekte Ergebnisse zurückgibt).

Die Optimierer können aus einigen vordefinierten Algorithmen ein Lego-Schloss bauen (ja, sie sind mehrere), aber sie können einfach keine neuen Algorithmen erstellen. Es braucht immer noch einen SQLEntwickler, um sie zu unterstützen.

Einige Leute erwarten jedoch, dass der Optimierer "den bestmöglichen Plan" erstellt, nicht "den besten verfügbaren Plan für diese Abfrage bei gegebener Implementierung der SQLEngine".

Und wie wir alle wissen, wird das Computerprogramm beschuldigt, wenn das Computerprogramm nicht den Erwartungen der Menschen entspricht, nicht die Erwartungen.

In den meisten Fällen kann die Neuformulierung einer Abfrage jedoch tatsächlich zu einem bestmöglichen Plan führen. Es gibt Aufgaben, bei denen es unmöglich ist, aber die neuen und wachsenden Verbesserungen SQLdieser Fälle werden immer weniger.

Es wäre jedoch schön, wenn die Anbieter einen einfachen Zugriff auf Funktionen wie "Indexbereich abrufen", "Zeile nach rowid" abrufen "usw. bereitstellen würden, z. B. CCompiler, mit denen Sie die Assembly direkt in die Sprache einbetten können.

Ich habe kürzlich einen Artikel dazu in meinem Blog geschrieben:

• Doppeltes Denken in SQL

Ich bin ein großer ORM-Befürworter und glaube immer noch, dass SQL sehr nützlich ist, obwohl es sicherlich möglich ist, schreckliche Dinge damit zu tun (genau wie alles andere). .

Ich betrachte SQL als eine supereffiziente Sprache, die keine Wiederverwendung von Code oder Wartbarkeit / Refactoring als Prioritäten hat.

Daher hat die blitzschnelle Verarbeitung Priorität. Und das ist akzeptabel. Sie müssen sich nur der Kompromisse bewusst sein, die für mich beträchtlich sind.

Aus ästhetischer Sicht habe ich als Sprache das Gefühl, dass einige Dinge fehlen, da es keine OO-Konzepte usw. gibt - es fühlt sich für mich wie ein sehr alter Verfahrenscode an. Aber es ist bei weitem der schnellste Weg, bestimmte Dinge zu tun, und das ist eine mächtige Nische!

Ich würde sagen, dass eine Datenbankabstraktionsschicht, die in einem Framework enthalten ist, eine gute Sache ist, da sie zwei sehr wichtige Probleme löst:

1. Es hält den Code eindeutig. Indem Sie das SQL in eine andere Ebene einfügen, die im Allgemeinen sehr dünn ist und nur die Grundlagen der Abfrage und Übergabe von Ergebnissen (auf standardisierte Weise) ausführen sollte, halten Sie Ihre Anwendung frei von SQL-Unordnung. Es ist der gleiche Grund, warum Webentwickler CSS und Javascript in getrennten Dateien ablegen (sollten). Wenn Sie dies vermeiden können, mischen Sie Ihre Sprachen nicht .

2. Viele Programmierer sind einfach schlecht darin, SQL zu verwenden. Aus irgendeinem Grund scheint eine große Anzahl von Entwicklern (insbesondere Webentwickler) sehr, sehr schlecht darin zu sein, SQL oder RDBMS im Allgemeinen zu verwenden. Sie behandeln die Datenbank (und SQL als Erweiterung) als den schmuddeligen kleinen Mittelsmann, den sie durchlaufen müssen, um an Daten zu gelangen. Dies führt zu äußerst schlecht durchdachten Datenbanken ohne Indizes, Tabellen, die auf zweifelhafte Weise auf Tabellen gestapelt sind, und sehr schlecht geschriebenen Abfragen. Oder schlimmer noch, sie versuchen zu allgemein zu sein (Expertensystem, irgendjemand?) Und können Daten nicht in sinnvoller Weise in Beziehung setzen.

Leider steht manchmal die Art und Weise, wie jemand versucht, ein Problem und die von ihm verwendeten Werkzeuge zu lösen, sei es aufgrund von Unwissenheit, Sturheit oder einer anderen Eigenschaft, in direktem Gegensatz zueinander, und viel Glück beim Versuch, ihn davon zu überzeugen. Daher ist eine Datenbankabstraktionsschicht nicht nur eine gute Vorgehensweise, sondern auch eine Art Sicherheitsnetz, da sie nicht nur die SQL aus den Augen des armen Entwicklers fernhält, sondern auch die Umgestaltung des Codes erheblich erleichtert. da alle Abfragen an einem Ort sind.

SQL ist ausgezeichnet für bestimmte Arten von Aufgaben, vor allem der Manipulation und Abrufen von Sätzen von Daten.

In SQL fehlen jedoch einige wichtige Tools zur Verwaltung von Änderungen und Komplexität (oder sie werden nur teilweise implementiert):

• Kapselung : Die Kapselungsmechanismen von SQL sind grob. Wenn Sie SQL-Code schreiben, müssen Sie alles über die Implementierung Ihrer Daten wissen. Dies begrenzt den Umfang der Abstraktion, den Sie erreichen können.

• Polymorphismus : Wenn Sie dieselbe Operation für verschiedene Tabellen ausführen möchten, müssen Sie den Code zweimal schreiben. (Man kann dies durch einfallsreiche Verwendung von Ansichten abmildern.)

• Sichtbarkeitskontrolle : Es gibt keinen Standard-SQL-Mechanismus, um Teile des Codes voreinander auszublenden oder in logische Einheiten zu gruppieren, sodass auf jede Tabelle, Prozedur usw. von jeder anderen aus zugegriffen werden kann, auch wenn dies unerwünscht ist.

• Modularität und Versionierung

Schließlich ist das manuelle Codieren von CRUD-Operationen in SQL (und das Schreiben des Codes zum Anschließen an den Rest der Anwendung) repetitiv und fehleranfällig.

Eine moderne Abstraktionsschicht bietet all diese Funktionen und ermöglicht es uns, SQL dort einzusetzen, wo es am effektivsten ist, während die störenden, sich wiederholenden Implementierungsdetails ausgeblendet werden. Es bietet Tools zur Überwindung der objektrelationalen Impedanzfehlanpassung , die den Datenzugriff bei der objektorientierten Softwareentwicklung erschwert.

SQL basiert auf der Mengenlehre, während die meisten Hochsprachen heutzutage objektorientiert sind. Objektprogrammierer denken normalerweise gerne in Objekten und müssen eine mentale Verschiebung vornehmen, um Set-basierte Tools zum Speichern ihrer Objekte zu verwenden. Im Allgemeinen ist es viel natürlicher (für den OO-Programmierer), nur Code in der Sprache seiner Wahl zu schneiden und im Anwendungscode so etwas wie object.save oder object.delete auszuführen, anstatt SQL-Abfragen schreiben und die Datenbank aufrufen zu müssen, um dies zu erreichen das gleiche Ergebnis.

Natürlich ist SQL manchmal für komplexe Aufgaben einfacher zu verwenden und effizienter, daher ist es gut, beide Technologietypen im Griff zu haben.

IMO, das Problem, das ich sehe, dass Leute mit SQL haben, hat nichts mit relationalem Design oder der SQL-Sprache selbst zu tun. Dies hat mit der Disziplin der Modellierung der Datenschicht zu tun, die sich in vielerlei Hinsicht grundlegend von der Modellierung einer Geschäftsschicht oder -schnittstelle unterscheidet. Fehler bei der Modellierung auf der Präsentationsebene sind im Allgemeinen viel einfacher zu korrigieren als auf der Datenebene, auf der mehrere Anwendungen die Datenbank verwenden. Diese Probleme sind dieselben wie bei der Modellierung einer Service-Schicht in SOA-Designs, bei denen Sie die aktuellen Verbraucher Ihres Service sowie die Eingabe- und Ausgabeverträge berücksichtigen müssen.

SQL wurde für die Interaktion mit relationalen Datenbankmodellen entwickelt. Es gibt andere Datenmodelle, die schon seit einiger Zeit existieren, aber die Disziplin, die Datenschicht richtig zu entwerfen, besteht unabhängig vom verwendeten theoretischen Modell, und daher hängen die Schwierigkeiten, die Entwickler normalerweise mit SQL haben, normalerweise mit Versuchen zusammen, eine nicht relationale zu erzwingen Datenmodell auf ein relationales Datenbankprodukt.

Zum einen ist es trivial, parametrisierte Abfragen zu verwenden, um Sie vor SQL-Injection-Angriffen zu schützen. Aus dieser Perspektive ist die Verwendung von Raw SQL riskanter, dh aus Sicherheitsgründen ist es einfacher, Fehler zu machen. Sie bieten auch häufig eine objektorientierte Perspektive auf Ihre Datenbank, sodass Sie diese Übersetzung nicht mehr durchführen müssen.

In letzter Zeit viel gehört? Ich hoffe, Sie verwechseln dies nicht mit der NoSql-Bewegung. Soweit mir bekannt ist, handelt es sich hauptsächlich um eine Gruppe von Personen, die NoSql für Web-Apps mit hoher Skalierbarkeit verwenden und anscheinend vergessen haben, dass SQL ein effektives Tool in einem Szenario ohne Web-App mit hoher Skalierbarkeit ist.

Im Geschäft mit der Abstraktionsschicht geht es nur darum, den Unterschied zwischen objektorientiertem Code und tabellenbasiertem Code wie SQL zu beseitigen. Normalerweise führt dies dazu, dass viel Kesselplatte und ein stumpfer Übergangscode zwischen den beiden geschrieben werden. ORM automatisiert dies und spart somit Zeit für Geschäftsleute.

Für erfahrene SQL-Programmierer sind die schlechten Seiten

• Ausführlichkeit
• Wie viele hier gesagt haben, ist SQL deklarativ, was bedeutet, dass die Optimierung nicht direkt ist . Es ist wie Rallye im Vergleich zu Rundstreckenrennen.
• Frameworks, die versuchen, alle möglichen Dialekte anzusprechen und keine Verknüpfungen von ihnen unterstützen
• Keine einfache Versionskontrolle.

Für andere sind die Gründe das

• Einige Programmierer sind schlecht in SQL. Wahrscheinlich, weil SQL mit Mengen arbeitet, während Programmiersprachen im Objekt- oder Funktionsparadigma arbeiten. Das Denken in Mengen (Vereinigung, Produkt, Schnittmenge) ist eine Frage der Gewohnheit, die manche Menschen nicht haben.
• Einige Operationen sind nicht selbsterklärend: dh zunächst ist nicht klar, wo und mit unterschiedlichen Sätzen gefiltert werden.
• Es gibt zu viele Dialekte

Das Hauptziel von SQL-Frameworks besteht darin, Ihre Eingabe zu reduzieren. Sie tun es irgendwie, aber zu oft nur für sehr einfache Abfragen. Wenn Sie versuchen, etwas Komplexes zu tun, müssen Sie Zeichenfolgen verwenden und viel eingeben. Frameworks, die versuchen, alles Mögliche zu handhaben, wie SQL Alchemy, werden wie eine andere Programmiersprache zu umfangreich.

[Update am 26.06.10] Kürzlich habe ich mit dem Django ORM-Modul gearbeitet . Dies ist das einzige würdige SQL-Framework, das ich gesehen habe. Und dieser macht die Arbeit mit Sachen viel. Komplexe Aggregate sind allerdings etwas schwieriger.

SQL ist keine schreckliche Sprache, es spielt manchmal einfach nicht so gut mit anderen.

Wenn Sie beispielsweise ein System haben, das alle Entitäten als Objekte in der einen oder anderen OO-Sprache darstellen möchte, kann die Kombination mit SQL ohne irgendeine Abstraktionsschicht ziemlich umständlich werden. Es gibt keine einfache Möglichkeit, eine komplexe SQL-Abfrage der OO-Welt zuzuordnen. Um die Spannung zwischen diesen Welten zu verringern, werden zusätzliche Abstraktionsebenen eingefügt (z. B. ein OR-Mapper).

SQL ist eine wirklich gute Sprache für die Datenmanipulation. Aus Entwicklersicht gefällt mir nicht, dass das Ändern der Datenbank Ihren Code beim Kompilieren nicht beschädigt ... Ich verwende also eine Abstraktion, die diese Funktion zum Preis der Leistung und möglicherweise der Ausdruckskraft der SQL-Sprache hinzufügt , weil Sie in den meisten Anwendungen nicht alles brauchen, was SQL hat.

Der andere Grund, warum SQL gehasst wird, sind relationale Datenbanken.

Der CAP- Satz wird populär:

Welche Ziele möchten Sie möglicherweise von einem Shared-Data-System?

• Starke Konsistenz: Alle Clients sehen dieselbe Ansicht, auch wenn Aktualisierungen vorhanden sind
• Hochverfügbarkeit: Alle Clients können eine Replik der Daten finden, auch wenn Fehler vorliegen
• Partitionstoleranz: Die Systemeigenschaften gelten auch dann, wenn das System partitioniert ist

Der Satz besagt, dass Sie immer nur zwei der drei CAP-Eigenschaften gleichzeitig haben können

Relationale Datenbankadresse Starke Konsistenz und Partitionstoleranz.

Immer mehr Menschen erkennen, dass relationale Datenbanken nicht das Patentrezept sind, und immer mehr Menschen lehnen sie zugunsten einer hohen Verfügbarkeit ab, da eine hohe Verfügbarkeit die horizontale Skalierung einfacher macht. Die horizontale Skalierung wird immer beliebter, da wir die Grenze des Moore-Gesetzes erreicht haben. Der beste Weg zur Skalierung besteht darin, mehr Maschinen hinzuzufügen.

Wenn die relationale Datenbank abgelehnt wird, wird auch SQL abgelehnt.

SQL weist viele Mängel auf, wie einige andere Poster hier gezeigt haben. Trotzdem bevorzuge ich die Verwendung von SQL gegenüber vielen Tools, die als Alternative angeboten werden, da die "Vereinfachungen" oft komplizierter sind als die, die sie eigentlich vereinfachen sollten.

Meine Theorie ist, dass SQL von einer Gruppe von Elfenbeinturm-Blau-Skifahrern erfunden wurde. Die gesamte nicht prozedurale Struktur. Klingt gut: Sag mir, was du willst und nicht wie du es machen willst. In der Praxis ist es jedoch oft einfacher, nur die Schritte anzugeben. Oft scheint dies der Versuch zu sein, Anweisungen zur Fahrzeugwartung zu geben, indem beschrieben wird, wie das Auto funktionieren soll, wenn Sie fertig sind. Ja, man könnte sagen: "Ich möchte, dass das Auto wieder 30 Meilen pro Gallone erreicht und mit diesem Summen wie diesem fährt ... hmmmm ... und usw." Aber wäre es nicht für alle einfacher? Sagen Sie einfach "Ersetzen Sie die Zündkerzen"? Und selbst wenn Sie herausfinden, wie eine komplexe Abfrage nicht prozedural ausgedrückt werden kann, erstellt das Datenbankmodul häufig einen sehr ineffizienten Ausführungsplan, um dorthin zu gelangen.

Und der Umgang mit Nullen macht mich verrückt! Ja, theoretisch muss es großartig geklungen haben, als jemand sagte: "Hey, wenn null unbekannt bedeutet, sollte das Hinzufügen eines unbekannten Werts zu einem bekannten Wert einen unbekannten Wert ergeben. Schließlich haben wir per Definition keine Ahnung, was der unbekannte Wert ist . " Theoretisch absolut wahr. In der Praxis, wenn wir 10.000 Kunden haben und genau wissen, wie viel Geld 9.999 uns schulden, aber es gibt einige Fragen zum geschuldeten Betrag des letzten, und das Management sagt: "Wie hoch sind unsere gesamten Forderungen?", Ja, die mathematisch korrekten Antwort ist "Ich weiß nicht". Die praktische Antwort lautet jedoch "Wir berechnen 4.327.287,42 USD, aber ein Konto ist fraglich, sodass diese Zahl nicht genau ist". Ich bin sicher, das Management würde viel lieber eine enge, wenn nicht bestimmte Zahl als einen leeren Blick bekommen.

Alles in allem würde ich immer noch lieber SQL verwenden als eine Schicht, die auf SQL aufbaut, die nur eine ganze Reihe von Dingen erstellt, die ich lernen muss, und dann muss ich wissen, dass dies letztendlich und manchmal in SQL übersetzt wird Ich kann einfach darauf vertrauen, dass die Übersetzung korrekt und effizient ausgeführt wird, aber wenn die Dinge komplex werden, kann ich das nicht. Jetzt muss ich die zusätzliche Ebene kennen, ich muss immer noch SQL kennen und ich muss wissen, wie sie übersetzt werden soll Ich kann die Ebene dazu bringen, SQL dazu zu bringen, das Richtige zu tun. Arggh.

• Jeder Anbieter erweitert die SQL-Syntax entsprechend seinen Anforderungen. Wenn Sie also keine einfachen Dinge tun, ist Ihr SQL-Code nicht portierbar.

• Die Syntax von SQL ist nicht orthogonal. zB haben die Anweisungen select, insert, update,und deletealle eine völlig unterschiedliche syntaktische Struktur.

Ich stimme Ihren Punkten zu, aber um Ihre Frage zu beantworten, ist eine Sache, die SQL so "schrecklich" macht, das Fehlen einer vollständigen Standardisierung von T-SQL zwischen Datenbankanbietern (SQL Server, Oracle usw.), was SQL-Code unwahrscheinlich macht vollständig tragbar. Datenbankabstraktionsschichten lösen dieses Problem, wenn auch mit Leistungskosten (manchmal sehr schwerwiegend).

Das Leben mit reinem SQL kann wirklich eine Hölle der Wartung sein. Für mich ist der größte Vorteil von ORMs die Möglichkeit, Code ohne langwierige "DB Refactoring" -Verfahren sicher umzugestalten. Es gibt gute Unit-Test-Frameworks und Refactoring-Tools für OO-Sprachen, aber ich muss zum Beispiel noch das Gegenstück von Resharper für SQL sehen.

Trotzdem haben alle DALs SQL hinter den Kulissen, und Sie müssen es wissen, um zu verstehen, was mit Ihrer Datenbank passiert, aber das tägliche Arbeiten mit einer guten Abstraktionsschicht wird einfacher.

Wenn Sie SQL nicht zu oft verwendet haben, ist das Hauptproblem meiner Meinung nach das Fehlen guter Entwicklertools.

Wenn Sie viel Erfahrung mit SQL haben, wurden Sie zu dem einen oder anderen Zeitpunkt durch die mangelnde Kontrolle über den Ausführungsplan frustriert. Dies ist ein inhärentes Problem in der Art und Weise, wie SQL den Anbietern angegeben wurde. Ich denke, SQL muss eine robustere Sprache werden, um die zugrunde liegende Technologie (die sehr leistungsfähig ist) wirklich zu nutzen.

Schreiben Sie mir schnell SQL, um ein Dataset zu paginieren, das in MySQL, Oracle, MSSQL, PostgreSQL und DB2 funktioniert.

Oh, richtig, Standard-SQL definiert keine Operatoren, um die Anzahl der zurückkommenden Ergebnisse und die Zeile, mit der begonnen werden soll, zu begrenzen.

Es gibt keine Liebe zu SQL, da SQL in Syntax, Semantik und aktueller Verwendung schlecht ist. Ich erkläre es:

• Die Syntax ist ein Cobol-Splitter, die gesamte Cobol-Kritik gilt hier (in geringerem Maße, um fair zu sein). Der Versuch, eine natürliche Sprache zu sein, ohne tatsächlich zu versuchen, eine natürliche Sprache zu interpretieren, erzeugt eine willkürliche Syntax (ist es DROP TABLE oder DROP, UPDATE TABLE, UPDATE oder UPDATE IN, DELETE oder DELETE FROM ...) und syntaktische Monstrositäten wie SELECT (wie viele Seiten) es füllen?)
• Die Semantik ist ebenfalls sehr fehlerhaft, Date erklärt sie ausführlich, aber es genügt zu beachten, dass eine dreiwertige boolesche Logik nicht wirklich zu einer relationalen Algebra passt, bei der eine Zeile nur Teil einer Tabelle sein kann oder nicht
• Eine Programmiersprache als Haupt- (und oft nur) Schnittstelle zu Datenbanken zu haben, erwies sich als eine wirklich schlechte Wahl und führte zu einer neuen Kategorie von Sicherheitslücken

Ich stimme den meisten Beiträgen hier zu, dass die Debatte über den Nutzen von SQL größtenteils subjektiv ist, aber ich denke, dass sie in der Art Ihrer Geschäftsanforderungen subjektiver ist.

Deklarative Sprachen sind, wie Stefan Steinegger betont hat, gut geeignet, um anzugeben, was Sie wollen, nicht wie Sie es tun wollen. Dies bedeutet, dass Ihre verschiedenen Implementierungen von SQL aus einer übergeordneten Perspektive anständig sind: Wenn Sie also nur einige Daten abrufen möchten und nichts anderes wichtig ist, können Sie sich damit zufrieden geben, relativ einfache Abfragen zu schreiben und die Implementierung von SQL auszuwählen das ist richtig für dich.

Wenn Sie auf einer viel "niedrigeren" Ebene arbeiten und all das selbst optimieren müssen, ist dies alles andere als ideal. Die Verwendung einer weiteren Abstraktionsebene kann hilfreich sein. Wenn Sie jedoch wirklich versuchen, die Methoden zur Optimierung von Abfragen usw. anzugeben, ist es etwas kontraintuitiv, beim Versuch der Optimierung einen Mittelsmann hinzuzufügen.

Das größte Problem, das ich mit SQL habe, ist wie bei anderen "standardisierten" Sprachen, es gibt nur sehr wenige echte Standards. Ich würde es fast vorziehen, eine ganz neue Sprache zwischen Sybase und MySQL lernen zu müssen, damit ich die beiden Konventionen nicht verwechsle.

Während SQL die Arbeit erledigt, hat es sicherlich Probleme ...

• es versucht gleichzeitig die Abstraktion auf hoher und niedriger Ebene zu sein , und das ist ... seltsam. Vielleicht sollten es zwei oder mehr Standards auf verschiedenen Ebenen gewesen sein.
• Standardmäßig ist dies ein großer Fehler . Viele Dinge gehen schief, wenn ein Standard entweder alles einrührt, zu viel von Implementierungen verlangt, zu wenig verlangt oder aus irgendeinem Grund das teilweise soziale Ziel, Anbieter und Implementierer zu motivieren, streng konforme interoperable vollständige Implementierungen zu erstellen, nicht erreicht. Sie können sicherlich nicht sagen, dass SQL irgendetwas davon getan hat. Schauen Sie sich einige andere Standards an und stellen Sie fest, dass Erfolg oder Misserfolg des Standards eindeutig ein Faktor für die erreichte nützliche Zusammenarbeit ist:
  • RS-232 ( Schlecht , nicht annähernd genug spezifiziert, selbst welcher Pin sendet und welcher Pin empfängt, ist optional, meine Güte. Sie können einhalten, aber immer noch nichts erreichen. Chance auf erfolgreiche Interop: wirklich niedrig, bis der IBM PC einen de facto nützlichen Standard erstellt hat .)
  • IEEE 754-1985 Floating Point ( Schlecht , Überreichweite: Kein einziger Supercomputer, keine wissenschaftliche Workstation oder kein RISC-Mikroprozessor hat es jemals übernommen, obwohl wir es schließlich nach 20 Jahren in HW gut implementieren konnten. Zumindest die Welt ist schließlich dazu gewachsen.)
  • C89, C99, PCI, USB, Java ( Gut , ob Standard oder Spezifikation, es ist ihnen gelungen, die strikte Einhaltung durch fast alle zu motivieren, und diese Einhaltung führte zu einer erfolgreichen Interoperation.)
• Es konnte nicht für die wohl wichtigste Datenbank der Welt ausgewählt werden . Dies ist zwar eher ein Datenpunkt als ein Grund, aber die Tatsache, dass Google Bigtable nicht SQL und nicht relational ist, ist für SQL eine Art Anti-Leistung.

Ich mag SQL nicht, aber ich möchte es auch nicht als Teil meiner Entwicklung schreiben müssen. Bei der DAL geht es nicht um die Markteinführung - eigentlich hätte ich nie gedacht, dass es eine DAL-Implementierung geben würde, die schneller wäre als direkte Abfragen aus dem Code. Aber das Ziel des DAL ist es Abstraktion . Abstraktion ist mit Kosten verbunden, und hier dauert die Implementierung länger.

Die Vorteile sind jedoch enorm. Schreiben nativer Tests um den Code, Verwenden von Ausdrucksklassen, stark typisierten Datensätzen usw. Wir verwenden eine Art "DAL", eine reine DDD-Implementierung unter Verwendung von Generics in C #. Wir haben also generische Repositorys, Implementierungen von Arbeitseinheiten (codebasierte Transaktionen) und logische Trennung. Wir können unsere Datensätze mit geringem Aufwand verspotten und tatsächlich vor der Datenbankimplementierung entwickeln. Der Aufbau eines solchen Frameworks war im Voraus mit Kosten verbunden, aber es ist sehr schön, dass die Geschäftslogik wieder der Star der Show ist. Wir verbrauchen jetzt Daten als Ressource und behandeln sie in der Sprache, die wir im Code nativ verwenden. Ein zusätzlicher Vorteil dieses Ansatzes ist die klare Trennung. Ich sehe beispielsweise keine Datenbankabfrage mehr auf einer Webseite. Ja, diese Seite benötigt Daten. Ja, die Datenbank ist beteiligt. Aber jetzt, egal woher ich Daten ziehe, gibt es einen (und nur einen) Ort, an dem ich in den Code gehen und ihn finden kann. Vielleicht keine große Sache bei kleineren Projekten, aber wenn Sie Hunderte von Seiten auf einer Site oder Dutzende von Fenstern in einer Desktop-Anwendung haben, können Sie es wirklich schätzen.

Als Entwickler wurde ich beauftragt, die Anforderungen des Unternehmens mit meinen logischen und analytischen Fähigkeiten umzusetzen - und unsere Framework-Implementierung ermöglicht es mir, jetzt produktiver zu sein. Als Manager möchte ich lieber, dass meine Entwickler ihre logischen und analytischen Fähigkeiten einsetzen, um Probleme zu lösen, als SQL zu schreiben. Die Tatsache, dass wir eine gesamte Anwendung erstellen können, die die Datenbank verwendet, ohne die Datenbank bis kurz vor dem Ende des Entwicklungszyklus zu haben, ist eine schöne Sache. Es ist nicht als Schlag gegen Datenbankprofis gedacht. Manchmal ist eine Datenbankimplementierung komplexer als die Lösung. SQL (und in unserem Fall insbesondere Views und Stored Procs) ist ein Abstraktionspunkt, an dem Code Daten als Service verwenden kann. In Geschäften, in denen eine eindeutige Trennung zwischen Daten- und Entwicklungsteams besteht, Dies hilft zu vermeiden, in einem Warteschleifenmuster zu sitzen, das auf die Implementierung und Änderungen der Datenbank wartet. Entwickler können sich auf die Problemdomäne konzentrieren, ohne den Mauszeiger über einen DBA zu halten, und der DBA kann sich auf die korrekte Implementierung konzentrieren, ohne dass ein Entwickler dies benötigtgerade jetzt .

Viele Beiträge hier scheinen zu argumentieren, dass SQL schlecht ist, weil es keine "Codeoptimierungs" -Funktionen hat und Sie keine Kontrolle über Ausführungspläne haben.

Was SQL-Engines gut können, ist, einen Ausführungsplan für eine schriftliche Anweisung zu erstellen , der auf die Daten und den tatsächlichen Inhalt ausgerichtet ist . Wenn Sie einen Blick über die Programmierseite hinaus werfen möchten, werden Sie feststellen, dass Daten mehr enthalten als nur Bytes, die zwischen Anwendungsebenen übertragen werden.