Warum keine Liebe zu SQL? [geschlossen]

116

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?

Travis
quelle
11
Was ist mit Typensicherheit?
Johnny
3
Genau an wen sind diese Abstraktionsschichten gerichtet? SQL ist keine Sprache, in der jeder gut ist, und daher richten sie sich möglicherweise an mittelmäßige Programmierer. SQL selbst ist für einen Nicht-Programmierer überhaupt keine gute Sprache.
David Thornley
27
@ David: Definiere eine (Computer-) Sprache, die "gut für einen Nicht-Programmierer" ist. Nicht-Programmierer, IMHO, sollten sich von Programmiersprachen (und im weiteren Sinne des Wortes SQL) fernhalten .
DevSolar
15
Alle Antworten sollten auch Wiki sein. Es ist einfach verrückt, dass Fragen und Antworten wie diese so viele Stimmen bekommen. Ich dachte das wäre ein technisches Forum? Sie können das Problem einer Person lösen, indem Sie schwierig zu schreibenden Code bereitstellen und ein oder zwei Stimmen erhalten. Beantworten Sie jedoch eine Frage wie diese und erhalten Sie eine Menge Stimmen. Das ist wirklich lahm, wenn du mich fragst.
KM.
6
@KM: Das Problem bei den Abstimmungen ist, dass sie stark von der Anzahl der Personen abhängen, die eine Antwort lesen. Ich beantwortete viele Fragen von NHibernate und Rhino Mocks, deren korrekte Beantwortung einige Zeit in Anspruch nahm - und wurde akzeptiert, aber keine einzige Abstimmung. Wenn Sie etwas Triviales über C # beantworten, erhalten Sie Dutzende von Stimmen. Stimmen sind einfach nicht fair. Schlagen Sie etwas auf meta.stckoverflow vor, wenn Sie etwas besser wissen.
Stefan Steinegger

Antworten:

132

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.

Stefan Steinegger
quelle
31
"Geben Sie einfach an, was Sie wollen - wir liefern so schnell wie möglich". Dieser deklarative Ansatz ist fantastisch und tatsächlich modern (denken Sie an LINQ). Es ist wahr, dass Sie manchmal die Geschwindigkeit optimieren müssen, und eine prozedurale Alternative zu SQL kann dann nützlich sein. Der Einfachheit halber würde ich die meiste Zeit immer noch deklaratives SQL verwenden.
MarkJ
4
MarkJ: Ich erinnere mich, dass ich WHERE-Klauseln neu angeordnet habe, um Abfragen in Oracle zu optimieren. Sie wurden von unten nach oben aufgelöst ... schrecklich.
Stefan Steinegger
16
Ich stimme vollkommen zu. IT-Mitarbeiter haben diese Faszination für nicht prozedurale Tools. Wäre es nicht so viel einfacher, wenn Sie dem Computer nur sagen, was Sie wollen, und er findet heraus, wie es geht! Ja, wenn der Computer dafür tatsächlich intelligent genug wäre. Aber es ist nicht so. Ich würde es mögen, wenn ich meinem Auto nur sagen könnte "Bring mich zu Oma" und es würde mich dorthin fahren. Aber das tut es nicht, also lasse ich nicht einfach das Lenkrad los und tue so, als würde das funktionieren. Vielleicht wird die Technologie eines Tages da sein, oder vielleicht ist das ein unmöglicher Traum. Aber heute ist es nicht da. (Fortsetzung ...)
Jay
12
Touché. Ihre Antwort beschreibt perfekt meine frühen Frustrationen mit SQL. Ich habe viel prozeduralen Code geschrieben, weil ich SQL nicht vertraute, um einen effizienten Ausführungsplan zu generieren. Als ich mich mit SQL besser auskannte, stellte ich fest, dass es tatsächlich sehr gut zu optimieren ist und dass richtig geschriebenes SQL normalerweise schneller ausgeführt wird als mein prozeduraler Code.
Kluge
5
@ Jay und die anderen SQL-Zweifler. Meiner Erfahrung nach muss man, um SQL effektiv nutzen zu können, in der Lage sein, in Mengen und nicht prozedural zu denken - genau so wird den meisten Programmierern das Denken beigebracht. SQL effektiv zu nutzen ist wirklich nicht so schwer und für jeden kompetenten Programmierer (wie jeder, der SO liest!) Erreichbar, aber es ist notwendig, sich die Mühe zu machen, in satzbasierter Logik zu denken, und die meisten Leute tun dies nicht Keine Sorge (und ich ändere gerade ein Programm, in dem der ursprüngliche Codierer aus genau diesem Grund alles mit Cursorn gemacht hat)
Cruachan
58

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!

Miguel Ventura
quelle
6
Sehr diplomatisch! (Und wahr, um zu booten!)
Joseph Ferris
2
Das Problem ist die Umkehrung der Abstraktion. SQL in einer relationalen Datenbank ist eine satzbasierte deklarative Umgebung. Es hat einen höheren Abstraktionsgrad als imperative Programmierung, objektorientiert oder nein.
Steven Huwig
2
Vielleicht, Steven, aber in Bezug auf die Anwendung führt es eine Low-Level-Funktion aus (auch wenn es auf extrem hohe Ebene funktioniert). Egal, welche verrückten Transformationen Sie auf Datenbankebene durchführen, am Ende des Tages ist es ein verherrlichter Getter und Setter. Oder Sie könnten es umgekehrt sehen, da es zu hoch ist, um mit der Anwendung gemischt zu werden, und separat beschlagnahmt und betrachtet werden muss. In jedem Fall hat das Halten des SQL außerhalb des Hauptanwendungscodes sehr greifbare Vorteile in Bezug auf Lesbarkeit und Refactoring.
Veröffentlicht
53

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.

Joonas Pulakka
quelle
19
Ich verstehe nicht, wie Inkompatibilitäten mit SQL-Dialekten ein so großer "Punkt" gegen SQL sein können. Das ist so, als würde man sagen, C ist Mist, weil man nicht einfach dieselbe Quelle in verschiedenen Linux-Distributionen kompilieren und ausführen kann. Wenn Ihr Unternehmen, und es ist eine große WENN, beschließt, den Datenbankanbieter zu wechseln, ist dies ein seltenes und großes Ereignis, das mehr bewegende Teile enthält als nur das Umschreiben von SQL.
Jeff Meatball Yang
7
Es ist kein Punkt gegen SQL, es ist ein Punkt für die Abstraktionsschichten. Sie können nicht einfach überall denselben C-Code kompilieren und ausführen. Dies ist ein Punkt für mehr plattformunabhängige Sprachen. Aber es macht weder SQL noch C "Mist": Die Abstraktionsschichten laufen sowieso über den tieferen Schichten.
Joonas Pulakka
8
@ Jeff: In C sind allgemeine Aufgaben Teil des Standards. In SQL ist es unmöglich, eine Ergebnismenge zu paginieren, ohne auf herstellerspezifisches SQL zuzugreifen.
Powerlord
4
Oh, und über die Seltenheit, den Datenbankanbieter zu wechseln: Worüber reden Sie? Macht die Seltenheit eines Unternehmens, das Betriebssysteme wechselt, plattformübergreifende Lösungen irrelevant? Sie wissen nicht immer im Voraus, worauf Ihr Produkt ausgeführt wird, daher ist es besser, sich auf allgemeinere Lösungen einzulassen.
Joonas Pulakka
3
@Joonas: Ich denke, ich wollte damit sagen, dass die SQL-Sprache (n) nicht das Problem ist (sind) - Die Frage, die SQL so schrecklich macht, und meine erste Reaktion, wie Ihre, ist, dass es nicht so ist. Aber ich wollte argumentieren, dass die Berücksichtigung verschiedener Dialekte nicht wirklich der Sinn von ORMs ist - wir hätten sie, selbst wenn wir nur eine Standardsprache hätten - ich denke, es ist mehr so, dass wir einen Weg brauchen, um normalisierte Daten in ein OO-Modell aufzulösen.
Jeff Meatball Yang
36

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.

Steven Huwig
quelle
7
In Bezug auf den ersten Punkt, dass Programmierer mit nichts anderem als einer zwingenden Sprache vertraut sind. In den nächsten Jahren wird es interessant sein zu sehen, ob / wie das Wiederaufleben der funktionalen Programmierung einen Unterschied macht. Momentan gibt es viel Hype um Sprachen wie Haskell, F # und Scala, was Entwickler so viel produktiver macht. Diese Art des "mathematischen" Denkens für Programmierer ist dem von SQL vorausgesetzten Wissen über relationale Algebra und relationale Tupelrechnung sehr ähnlich. Vielleicht wird das native SQL-Set-basierte Denken mit der Zeit wieder aufleben!
Trevor Tippins
Ich sollte klarstellen, dass ich "jene Programmierer meinte, die mit nichts anderem als zwingender Programmierung vertraut sind", nicht dass alle Programmierer sich damit nicht wohl fühlen.
Steven Huwig
+1, gut gesagt. Und als jemand, der dort die ersten Jahre als professioneller Programmierer in der vorrelationalen Datenbank verbracht hat, finde ich es ehrlich gesagt erstaunlich, dass jeder außer speziellen Aufgaben in diese Zeit zurückkehren möchte. Ein Tag, an dem Code geschrieben wird, der eine DL / 1-Baumstruktur durchquert, sollte ausreichen, um jeden zu überzeugen.
Cruachan
Das Problem ist, dass es viele zwanghafte Programmierer gibt, die lieber ein paar hundert Zeilen faden Codes herausschlagen, als etwa eine Stunde lang über Dinge nachzudenken.
Steven Huwig
Sie sollten eine Stunde lang nicht über Dinge nachdenken müssen, um ein paar Codezeilen zu schreiben oder zu verstehen. Zeitraum.
Andrew
23

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.

Trevor Tippins
quelle
16

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.

Mark Schultheiss
quelle
11

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.

Nikolay R.
quelle
2
Das Unglückliche ist, dass es sehr verlockend ist, einfach einfachen Prozedurcode in eine gespeicherte Prozedur zu stecken. Und es funktioniert gut. BIS jemand es warten / einige Ausnahmen hinzufügen muss, etc ...
Brian Knoblauch
5
-1, ähm, genau das ist der Punkt, SQL ist so konzipiert, dass es satzbasiert ist, und das ist die Stärke davon. In prozeduralen Begriffen zu denken bedeutet, dass Sie falsch denken.
Cruachan
1
Dieser Schraubenzieher ist scheiße! Es ist so schwer, damit in die Nägel zu schlagen.
Casey Rodarmor
9

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:

Quassnoi
quelle
7

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!

Brian MacKay
quelle
7

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.

Freigegeben
quelle
6

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.

Jeff Sternal
quelle
Was ist mit Schemata zur Sichtbarkeitskontrolle?
Drei-Werte-Logik
5

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.

Peter Bailey
quelle
5

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.

Thomas
quelle
4

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.

Tvanfosson
quelle
2
Stimmt, aber dafür brauchen Sie kein ORM
finnw
2
Die Verwendung parametrisierter Abfragen ist beim direkten Schreiben von SQL trivial, vorausgesetzt, Sie verfügen über eine anständige Datenbankschnittstellenschicht (dh eine, die Platzhalter unterstützt). $dbh->do("DELETE FROM my_table WHERE some_value = ?", undef, $target_value); Dort. Getan.
Dave Sherohman
Ich habe nie gesagt, dass Sie mit RAW SQL keine parametrisierten Abfragen schreiben können. Ich sagte, dass die Verwendung von Raw SQL riskanter ist, da Sie es selbst implementieren müssen. Ich habe viele Fälle von SQL-Rohcode gesehen, in denen die Abfrage nicht parametrisiert ist. ORMs bieten diesen Vorteil automatisch.
Tvanfosson
2
Richtig, aber das Vermeiden von SQL-Injection ist auch ohne vorbereitete Anweisungen trivial einfach. Bei jedem Projekt schreibe ich eine einfache Funktion, die Anführungszeichen um eine Zeichenfolge setzt und eingebettete Anführungszeichen ordnungsgemäß umgeht. Das Schreiben dauert ungefähr fünfzehn Minuten, auch wenn ich es nicht aus einem früheren Projekt kopiere. Dann verwende ich das für jedes Literal, das ich in eine Abfrage einbette. Was mich nervt, ist, dass Programmierer dies nicht tun! Nehmen Sie sich keine fünfzehn Minuten Zeit, um eine absichtliche oder - wahrscheinlich häufigere - versehentliche SQL-Injektion zu vermeiden! Warum nicht?!
Jay
3
Jay, berücksichtigt diese "einfache Funktion, die Anführungszeichen um eine Zeichenfolge setzt und eingebetteten Anführungszeichen ordnungsgemäß entgeht" den aktuell auf dem Server verwendeten Zeichensatz?
Ygrek
4

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.

Streit
quelle
4

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.

culebrón
quelle
3

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).

Joachim Sauer
quelle
Warum ist SQL schuld daran, dass OO-Sprachen nicht gut darauf abgestimmt sind? Wenn Sie einen Dienst verwenden, passen Sie sich seiner Schnittstelle an oder verwenden Sie ihn nicht.
KM.
2
Niemand sagte, dass es SQLs Fehler ist. Die Verkehrssprache des DB-Zugriffs ist SQL. Die Verkehrssprache der Geschäftslogik ist eine OO-basierte. Diese beiden passen ohne Hilfe nicht perfekt zusammen. Kein "Fehler" oder "Problem" hier, nur einige Anforderungen ("machen sie übereinstimmen") und eine allgemein akzeptierte Lösung ("verwenden Sie einen OR-Mapper").
Joachim Sauer
Joachim Sauer sagte, SQL sei keine schreckliche Sprache, es spiele einfach nicht so gut mit anderen. Für mich klingt es so, als hätte jemand gesagt, es sei SQLs Fehler
KM.
1
@KM: Wollen Sie damit sagen, dass Französisch und Deutsch schlechte Sprachen sind? Sie spielen nicht so gut mit Englisch.
David Thornley
3

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.

Nicolas Dorier
quelle
3

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.

Jay
quelle
3
Die gesamte Idee der relationalen Datenbank war das Produkt von Blue Skyern aus Elfenbeintürmen. Frühe relationale Datenbanken hatten im Vergleich zu den damals aktuellen hierarchischen Datenbanken eine schreckliche Leistung und es dauerte lange, bis sie sich etablierten. Die Kraft der Abstraktion war so groß, dass hierarchische Datenbanken im Wesentlichen der Vergangenheit angehören (nicht, dass es wahrscheinlich noch keine IMS- und CODASYL-Datenbanken gibt). Es musste sehr, sehr gut funktioniert haben.
David Thornley
1
Aber das Management würde keine "nahe, wenn nicht bestimmte Nummer" sehen - sie würden eine falsche Nummer sehen. Vielleicht schuldet dieser Endkunde viel Geld. Dann wäre das Management über diese falsche Nummer sehr unglücklich.
HTTP 410
RoadWarrior: Ja, es ist möglich, dass Sie 10.000 Kunden haben, die Ihnen jeweils 10 US-Dollar schulden, und einen Kunden, der Ihnen 10 Millionen US-Dollar schuldet. Wenn dies jedoch der Fall wäre, würde jeder, der einen AR-Bericht anfordert, den Namen des Kunden wahrscheinlich sehr gut kennen und genau wissen, was mit ihm los ist. Okay, ich bin sicher, es gibt Zeiten, in denen keine Antwort besser ist als eine Antwort, die so unzuverlässig ist, dass sie bedeutungslos ist. Aber das ist mein Punkt: SQL basiert auf solchen theoretischen Überlegungen: Eine dogmatische "alles andere als Perfektion ist wertlos". ...
Jay
... Im wirklichen Leben ist in 95% der Fälle eine ungefähre Antwort viel besser als ein leerer Blick. Wenn ich mir mein Scheckbuch ansehe, weiß ich, dass es durchaus möglich ist, dass ich einen Rechenfehler gemacht oder vergessen habe, einen Scheck einzutragen. Das Gleichgewicht könnte durchaus eine Annäherung sein. Aber wenn ich weiß, dass ich "ungefähr 1.000 Dollar" habe, habe ich keine Bedenken, einen Scheck über 50 Dollar auszustellen, und ich werde erkennen, dass das Ausstellen eines Schecks über 10.000 Dollar zwecklos ist.
Jay
Nun, ich habe ein Geschäft geführt und es ist nie 10K gegenüber 1. IMX, es ähnelt eher 20 Unbekannten pro 100 Bekannten (das Pareto-Prinzip). Und einige dieser 20 schuldeten uns viel Geld, weshalb der tatsächliche Betrag umstritten war. Auch dies ist das Pareto-Prinzip.
HTTP 410
3

• 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.

David R Tribble
quelle
1
Wie macht das die Syntax nicht orthogonal?
Amok
1
Die Sprache könnte so gestaltet sein, dass alle diese imperativen Anweisungen eine allgemeinere Syntax haben, insbesondere zwischen den Operationen insertund update, die semantisch nahezu identisch, syntaktisch jedoch völlig unterschiedlich sind.
David R Tribble
2

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).

MusiGenesis
quelle
2
Ich verstehe nicht, wie Inkompatibilitäten mit SQL-Dialekten ein so großer "Punkt" gegen SQL sein können. Das ist so, als würde man sagen, C ist Mist, weil man nicht einfach dieselbe Quelle in verschiedenen Linux-Distributionen kompilieren und ausführen kann.
Jeff Meatball Yang
1
@ Jeff: Ich denke nicht, dass es ein großer Punkt gegen SQL ist. Deshalb habe ich "Ich stimme Ihren Punkten zu" gesagt und "schrecklich" in Anführungszeichen gesetzt. Ich selbst bevorzuge SQL gegenüber Datenabstraktionsschichten, obwohl ich froh bin, dass es Dinge wie NHibernate gibt, weil sie viel besser sind als der selbstgewachsene Mist, der sich früher vermehrt hat.
MusiGenesis
1
Richtig - ich verwende auch Abstraktionsschichten - ich wollte damit sagen, dass für mich die SQL-Sprache nicht das Problem ist - es ist die Umwandlung normalisierter Daten in Objekte, weshalb Abstraktionsschichten nützlich sind.
Jeff Meatball Yang
2

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.

ovolko
quelle
Der Umgang mit Instanzen von Objekten im Speicher unterscheidet sich erheblich von den Daten, die physisch in einer Datenbank gespeichert sind. Es gibt mehr Schmerzbehebung bei schlechten Designs und möglicherweise massive Leistungsschwankungen aufgrund von "kleinen Dingen"
KM.
2

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.

Jeff Fleischbällchen Yang
quelle
2

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.

Powerlord
quelle
5
Warum versuchen Sie, mit Ihrem Code auf all diese Umgebungen abzuzielen? Schreiben Sie mir C-Code für Threads, die unter Mac OS 9, Windows NT, OS / 2 Warp und Solaris funktionieren.
Steven Huwig
2
@Steven Huwig: Ich würde wahrscheinlich eine Abstraktionsschicht verwenden, um das für mich zu tun ... genau das stellte die Frage.
Powerlord
@Steven: Ich verwende Frameworks und Abstraktionsebenen für einige Dinge, bei denen ich plattformunabhängig sein muss. In den meisten Fällen ist die Unabhängigkeit von Datenbanken jedoch viel wichtiger. Selbst wenn Sie Ihre Software nur für die Ausführung unter Windows bereitstellen, werden Sie nach dem Verkauf an größere Unternehmen auf alles stoßen, von "Wir bevorzugen OSS, unterstützen Sie MySQL" bis zu "Wir verwenden Oracle | MSSQL | wie auch immer" ein Unternehmensstandard, unterstützen Sie ihn? "
Fredrik
2

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
stupito
quelle
1

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.

NateDSaint
quelle
Sie können sich einiges von diesem Schmerz ersparen, indem Sie MySQL einfach nicht verwenden. ;)
Steven Huwig
1

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.
DigitalRoss
quelle
0

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 .

Joseph Ferris
quelle
1
Downvoter - möchten Sie erklären, warum oder einfach auf den Down-Button klicken, um alles zu erfahren, mit dem Sie nicht einverstanden sind?
Joseph Ferris
0

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.

adriaan
quelle