web-dev-qa-db-de.com

Warum SQL-Datenbank verwenden?

Ich bin nicht ganz sicher, dass stackoverflow ein Platz für eine solche allgemeine Frage ist, aber versuchen wir es einmal.

Da ich der Notwendigkeit ausgesetzt war, Anwendungsdaten irgendwo zu speichern, habe ich immer MySQL oder sqlite verwendet, nur weil es immer so ist. Da es so aussieht, als würde die ganze Welt diese Datenbanken nutzen (vor allem Softwareprodukte, Frameworks usw.), ist es für einen beginnenden Entwickler wie mich ziemlich schwierig, darüber nachzudenken, ob dies eine gute Lösung ist oder nicht.

Ok, sagen wir, wir haben eine objektorientierte Logik in unserer Anwendung, und Objekte sind irgendwie miteinander verwandt. Wir müssen diese Logik der Speicherlogik zuordnen, daher sind auch Beziehungen zwischen Datenbankobjekten erforderlich. Das führt dazu, dass wir relationale Datenbanken verwenden, und ich bin damit einverstanden. Um es einfach zu sagen, müssen unsere Datenbanktabellenzeilen manchmal Verweise auf die Zeilen anderer Tabellen haben. Aber warum sollte SQL-Sprache für die Interaktion mit einer solchen Datenbank verwendet werden?

SQL-Abfrage ist eine Textnachricht. Ich kann verstehen, dass dies eine gute Idee ist, um wirklich zu verstehen, was es bewirkt. Aber ist es nicht dumm, Texttabellen- und -spaltennamen für einen Teil der Anwendung zu verwenden, den niemand nach der Bereitstellung gesehen hat? Wenn Sie einen Datenspeicher von Grund auf neu schreiben müssten, hätten Sie diese Art von Lösung nie verwendet. Persönlich hätte ich einen "kompilierten DB-Abfrage-Bytecode" verwendet, der einmal innerhalb einer Client-Anwendung zusammengebaut und an die Datenbank übergeben würde. Und es würde sicherlich Tabellen und Doppelpunkte nach ID-Nummern benennen, nicht nach ASCII-Zeichenketten. Im Falle von Änderungen in der Tabellenstruktur könnten diese Byte-Abfragen gemäß dem neuen Datenbankschema erneut kompiliert werden, das in XML oder ähnlich gespeichert wird.

Was sind die Probleme meiner Idee? Gibt es einen Grund für mich, es nicht selbst zu schreiben und stattdessen die SQL-Datenbank zu verwenden?

EDITUm meine Frage klarer zu machen. Die meisten Antworten behaupten, dass SQL als Textabfrage den Entwicklern hilft, die Abfrage selbst besser zu verstehen und einfacher zu debuggen. Ich persönlich habe seit einiger Zeit keine Leute gesehen, die SQL-Abfragen von Hand schreiben. Alle, die ich kenne, einschließlich ich, verwenden ORM. Diese Situation, in der wir eine neue Abstraktionsebene zum Ausblenden von SQL aufbauen, führt dazu, zu überlegen, ob wir SQL benötigen oder nicht. Ich wäre Ihnen sehr dankbar, wenn Sie einige Beispiele nennen würden, in denen SQL absichtlich ohne ORM verwendet wird und warum.

EDIT2 SQL ist eine Schnittstelle zwischen einem Menschen und einer Datenbank. Die Frage ist Warum müssen wir sie für die Interaktion zwischen Anwendung und Datenbank verwenden?Ich frage immer noch nach Beispielen, wie Menschen SQL schreiben/debuggen.

55
martinthenext

Wenn Sie nur einige Anwendungsdaten irgendwo speichern müssen, könnte ein allgemeines RDBMS oder sogar SQLite ein Overkill sein. Das Serialisieren Ihrer Objekte und das Schreiben in eine Datei kann in manchen Fällen einfacher sein. Ein Vorteil von SQLite besteht darin, dass alle diese Informationen in einer einzigen Datei enthalten sind. Ein Nachteil ist, dass es schwieriger ist, es zu lesen. Wenn Sie beispielsweise Ihre Daten in YAML serialisieren, können Sie die Datei mit einem beliebigen Texteditor oder einer Shell lesen.

Persönlich hätte ich einige .__ verwendet. Bytecode "kompilierte DB-Abfrage", dieser würde einmal in einem .__ zusammengebaut. Client-Anwendung und an die .__ übergeben. Datenbank.

So funktionieren einige Datenbank-APIs. Überprüfen Sie statische SQL und vorbereitete Anweisungen.

Gibt es einen Grund, warum ich nicht schreibe es selbst und benutze SQL Datenbank statt?

Wenn Sie viele Funktionen benötigen, ist es manchmal einfacher, eine vorhandene RDMBS zu verwenden, als Ihre eigene Datenbank von Grund auf zu schreiben. Wenn Sie nicht viele Funktionen benötigen, kann eine einfachere Lösung klüger sein.

Bei Datenbankprodukten geht es darum, zu vermeiden, dass die Datenbankschicht für jedes neue Programm geschrieben wird. Ja, eine moderne RDMBS passt nicht immer zu jedem Projekt. Dies liegt daran, dass sie sehr allgemein gehalten sind. In der Praxis erhalten Sie daher immer zusätzliche Funktionen, die Sie nicht benötigen. Das bedeutet nicht, dass es besser ist, eine individuelle Lösung zu haben. Der Handschuh muss nicht immer perfekt passen.

UPDATE:

Warum aber SQL-Sprache für .__ verwenden? Interaktion mit einer solchen Datenbank?

Gute Frage.

Die Antwort darauf kann in dem Originaldokument gefunden werden, das das relationale Modell Ein relationales Datenmodell für große gemeinsam genutzte Datenbanken von EF Codd beschreibt, das 1970 von IBM veröffentlicht wurde. Dieses Dokument beschreibt die Probleme mit dem Bestehenden Datenbank-Technologien der Zeit und erklärt, warum das relationale Modell überlegen ist.

Der Grund für die Verwendung des relationalen Modells und damit einer logischen Anfragesprache wie SQL liegt in der Datenunabhängigkeit. 

Datenunabhängigkeit wird in der Arbeit definiert als:

"... die Unabhängigkeit von Anwendungsprogrammen und Terminalaktivitäten von der Zunahme der Datentypen und von Änderungen der Datendarstellungen."

Vor dem relationalen Modell wurde die dominierende Technologie für Datenbanken als das Netzwerkmodell bezeichnet. In diesem Modell musste der Programmierer die Struktur der Daten auf der Festplatte kennen und den Baum oder das Diagramm manuell durchqueren. Das relationale Modell ermöglicht das Schreiben einer Abfrage gegen das konzeptionelle oder logische Schema, das unabhängig von der physischen Darstellung der Daten auf der Festplatte ist. Diese Trennung des logischen Schemas vom physischen Schema ist der Grund, warum wir das relationale Modell verwenden. Weitere Informationen zu diesem Problem sind hier einige Folien aus einer Datenbankklasse. Im relationalen Modell verwenden wir logikbasierte Abfragesprachen wie SQL, um Daten abzurufen Codds Papier geht detaillierter auf die Vorteile des relationalen Modells ein. Lies es vor. 

SQL ist eine Abfragesprache, die im Gegensatz zu den üblicherweise in Forschungsarbeiten verwendeten Abfragesprachen leicht in einen Computer einzugeben ist. Forschungsarbeiten verwenden im Allgemeinen Beziehungsalgebra oder Beziehungsrechnung, um Abfragen zu schreiben.

Zusammenfassend verwenden wir SQL, weil wir das relationale Modell für unsere Datenbanken verwenden.

Wenn Sie das relationale Modell verstehen, ist es nicht schwer zu verstehen, warum SQL so ist wie es ist. Im Grunde müssen Sie das Beziehungsmodell und die Datenbank-Interna eingehender studieren, um wirklich zu verstehen, warum wir SQL verwenden. Es könnte sonst ein bisschen ein Rätsel sein.

UPDATE 2:

SQL ist eine Schnittstelle zwischen einem Menschen und eine Datenbank. Die Frage ist, warum wir müssen es für .__ verwenden. Anwendung/Datenbank-Interaktion? ICH Bitten Sie immer noch um Beispiele von Menschen SQL schreiben/debuggen.

Da es sich bei der Datenbank um eine relationale Datenbank handelt, versteht sie nur relationale Abfragesprachen. Intern verwendet es eine relationale Algebra-ähnliche Sprache zum Angeben von Abfragen, die dann in einen Abfrageplan umgewandelt werden. Wir schreiben unsere Abfrage also in einer Form, die wir verstehen können (SQL). Die Datenbankdatenbank verwendet unsere SQL-Abfrage und wandelt sie in ihre interne Abfragesprache um. Dann nimmt es die Abfrage und versucht, einen "Abfrageplan" zum Ausführen der Abfrage zu finden. Dann führt es den Abfrageplan aus und gibt das Ergebnis zurück.

Irgendwann müssen wir unsere Abfrage in einem Format kodieren, das von der Datenbank verstanden wird. Die Datenbank weiß nur, wie sie SQL in ihre interne Darstellung konvertieren kann, daher gibt es irgendwo in der Kette immer SQL. Es kann nicht vermieden werden.

Wenn Sie ORM verwenden, fügen Sie einfach eine Ebene über SQL hinzu. Die SQL ist immer noch da, sie ist nur versteckt. Wenn Sie eine übergeordnete Schicht für die Übersetzung Ihrer Anforderung in SQL verwenden, müssen Sie SQL nicht direkt schreiben. Manchmal verfügen wir nicht über eine solche Ebene, die die erforderlichen Abfragen ausführen kann. Daher müssen wir SQL verwenden.

23
Jay

Jeder, den ich kenne, einschließlich ich, verwendet ORM

Seltsam. Jeder, den ich kenne, auch ich, schreibt den Großteil der SQL noch immer von Hand. In der Regel erhalten Sie strengere, leistungsfähigere Abfragen als mit einer generierten Lösung. Und abhängig von Ihrer Branche und Anwendung ist diese Geschwindigkeit/Materie. Manchmal viel. Ja, ich benutze LINQ manchmal für ein schnelles n-Dirty, bei dem es mir egal ist, wie die resultierende SQL aussieht, aber bislang schlägt nichts automatisiertes handgestimmtes SQL für Leistung, wenn eine große Datenbank in einem Lastumgebung ist wirklich wichtig.

43
Donnie

Angesichts der Tatsache, dass Sie MySQL und SQLite verwendet haben, kann ich Ihren Standpunkt vollständig verstehen. Die meisten DBMS verfügen über Funktionen, die einige Programmierungen von Ihrer Seite erfordern, während Sie sie kostenlos von der Datenbank erhalten:

  • Indizes - Sie können große Datenmengen speichern und können dennoch aufgrund von Indizes sehr schnell filtern und suchen. Natürlich können Sie Ihre eigene Indizierung implementieren, aber warum das Rad neu erfinden

  • Datenintegrität - Die Verwendung von Datenbankfunktionen wie das Kaskadieren von Fremdschlüsseln kann die Datenintegrität im gesamten System sicherstellen. Sie müssen lediglich die Beziehung zwischen den Daten angeben, und das System kümmert sich um den Rest. Natürlich könnten Sie auch hier Einschränkungen im Code implementieren, aber es ist mehr Arbeit. Betrachten Sie zum Beispiel den Löschvorgang, bei dem Sie Code in den Destruktor des Objekts schreiben müssten, um alle abhängigen Objekte zu verfolgen und entsprechend zu handeln

  • fähigkeit, mehrere Anwendungen in verschiedenen Programmiersprachen geschrieben zu haben, auf verschiedenen Betriebssystemen zu arbeiten, einige sogar im Netzwerk verteilt - alle mit den gleichen Daten in einer gemeinsamen Datenbank gespeichert

  • unkomplizierte Implementierung von Beobachtermuster über Trigger. Es gibt viele Fälle, in denen nur einige Daten von anderen Daten abhängen und sich nicht auf den Anwendungsaspekt der Benutzeroberfläche auswirken. Die Sicherstellung der Konsistenz kann sehr schwierig sein oder viel Programmierung erfordern. Natürlich können Sie ein auslöserähnliches Verhalten mit Objekten implementieren, dies erfordert jedoch mehr Programmierung als eine einfache SQL-Definition

11
Milan Babuškov

Hier gibt es einige gute Antworten. Ich werde versuchen, meine zwei Cents hinzuzufügen.

Ich mag SQL, ich kann ziemlich leicht darin nachdenken. Die Abfragen, die von Layern über der DB (wie ORM-Frameworks) erzeugt werden, sind normalerweise abscheulich. Sie wählen jede Menge zusätzliches Material aus, nehmen an Dingen teil, die Sie nicht brauchen, usw .; Dies alles, weil sie nicht wissen, dass Sie nur einen kleinen Teil des Objekts in diesem Code haben möchten. Wenn Sie hohe Leistung benötigen, müssen Sie häufig einige benutzerdefinierte SQL-Abfragen in einem ORM-System verwenden, um einige Engpässe zu beschleunigen.

Warum SQL? Wie andere gesagt haben, ist es für Menschen einfach. Es ist ein guter kleinster gemeinsamer Nenner. Jede Sprache kann bei Bedarf SQL-Befehle erstellen und Befehlszeilenclients aufrufen, und sie ist fast immer eine gute Bibliothek. 

Ist das Parsen der SQL ineffizient? Etwas. Die Grammatik ist ziemlich strukturiert, es gibt also keine Unklarheiten, die den Parser wirklich schwer machen würden. Die eigentliche Sache ist, dass der Aufwand für das Parsen von SQL im Grunde nichts ist.

Angenommen, Sie führen eine Abfrage wie "SELECT x FROM table WHERE id = 3" aus, und wiederholen Sie den Vorgang erneut mit 4, dann 5. In diesem Fall kann der Analyse-Overhead vorhanden sein. Deshalb haben Sie Aussagen vorbereitet (wie andere bereits erwähnt haben). Der Server parst die Abfrage einmal und kann 3 und 4 und 5 eintauschen, ohne dass alles repariert werden muss.

Aber das ist der triviale Fall. In der Praxis verbindet Ihr System möglicherweise 6 Tabellen und muss Hunderttausende Datensätze abrufen (wenn nicht mehr). Es kann eine Abfrage sein, die Sie stundenlang in einem Datenbankcluster ausführen lassen, da dies in Ihrem Fall die beste Vorgehensweise ist. Selbst bei einer Abfrage, deren Ausführung nur eine oder zwei Minuten dauert, ist die Zeit zum Parsen der Abfrage im Wesentlichen frei, verglichen mit dem Abrufen von Datensätzen von der Festplatte und dem Sortieren/Aggregieren/etc. Der Aufwand für das Senden des ext "LEFT OUTER JOIN ON" beträgt nur wenige Bytes im Vergleich zum Senden des speziell codierten Bytes 0x3F. Wenn Ihre Ergebnismenge jedoch 30 MB beträgt (ganz zu schweigen von Gigs +), sind diese wenigen zusätzlichen Bytes wertlos im Vergleich dazu, dass Sie sich nicht mit einem speziellen Abfrage-Compilerobjekt herumschlagen müssen.

Viele Leute verwenden SQL für kleine Datenbanken. Der größte, mit dem ich zu tun habe, ist nur ein paar Dutzend Gigs. SQL wird für alles von kleinen Dateien (wie kleine SQLite-DBs) bis zu Terabyte-Oracle-Clustern verwendet. In Anbetracht seiner Leistungsfähigkeit ist es tatsächlich ein überraschend einfacher und kleiner Befehlssatz.

10
MBCook

Aber warum sollten Sie SQL-Sprache für die Interaktion mit einer solchen Datenbank verwenden?

Ich denke, es ist aus dem gleichen Grund, dass Sie eine für den Benutzer lesbare Sprache (Quellcode) für die Interaktion mit dem Compiler verwenden.

Persönlich hätte ich etwas "kompilierten DB-Abfrage" -Bytecode verwendet, der einmal innerhalb einer Client-Anwendung zusammengebaut und an die Datenbank übergeben würde.

Dies ist eine vorhandene (optionale) Funktion von Datenbanken, die als "gespeicherte Prozeduren" bezeichnet wird.


Bearbeiten:

Ich wäre Ihnen sehr dankbar, wenn Sie einige Beispiele nennen würden, in denen SQL absichtlich ohne ORM verwendet wird und warum

Als ich mein eigenes ORM implementierte, implementierte ich das ORM-Framework mit ADO.NET: Die Verwendung von ADO.NET schließt die Verwendung von SQL-Anweisungen in seine Implementierung ein.

9
ChrisW
  • Es ist ein allgegenwärtiger Standard. So ziemlich jede Programmiersprache hat eine Möglichkeit, auf SQL-Datenbanken zuzugreifen. Versuchen Sie das mit einem proprietären Binärprotokoll.
  • Jeder weiß es. Sie finden Experten leicht, neue Entwickler werden es in gewissem Maße ohne Schulung verstehen
  • SQL ist sehr eng mit dem relationalen Modell verbunden, das hinsichtlich Optimierung und Skalierbarkeit gründlich untersucht wurde. Es erfordert jedoch immer noch ein manuelles Anpassen (Indexerstellung, Abfragestruktur usw.), was aufgrund der Textschnittstelle relativ einfach ist.
9

Nach all den Bearbeitungen und Kommentaren scheint der Hauptpunkt Ihrer Frage zu sein: Warum ist SQL eigentlich eher eine Mensch/Datenbank-Schnittstelle als eine Anwendungs-/Datenbank-Schnittstelle?

Und die sehr einfache Antwort auf die das -Frage lautet: Denn genau das war es ursprünglich beabsichtigt.

Die Vorgänger von SQL (wobei QUEL vermutlich der wichtigste ist) sollten genau das sein: eine QUERY-Sprache, d. H. Eine Sprache, die weder INSERT, UPDATE noch DELETE hatte.

Darüber hinaus sollte es eine Abfragesprache sein, die von jedem Benutzer verwendet werden kann, vorausgesetzt, der Benutzer kennt die logische Struktur der Datenbank und weiß offensichtlich, wie er diese logische Struktur in der von ihm verwendeten Abfragesprache ausdrücken kann.

Die ursprünglichen Ideen hinter QUEL/SQL waren, dass eine Datenbank mit "nur einem denkbaren Mechanismus" erstellt wurde, dass die "echte" Datenbank wirklich alles sein könnte (z. B. eine einzige gigantische XML-Datei - obwohl 'XML' keine gültige Option war zu der Zeit), und dass es "irgendeine Art von Maschinerie" gäbe, die es verstanden hat, die tatsächliche Struktur dieses "alles" in die logische relationale Struktur umzuwandeln, wie sie vom SQL-Benutzer wahrgenommen wurde.

Die Tatsache, dass die zugrundeliegenden Strukturen, um dies tatsächlich zu erreichen, erforderlich sind, um sie "relational zu betrachten", wurde damals nicht so gut verstanden wie heute.

7
Erwin Smout

Ja, es ist ärgerlich, SQL-Anweisungen zum Speichern und Abrufen von Objekten schreiben zu müssen.

Aus diesem Grund hat Microsoft in C # und VB.NET beispielsweise LINQ (Language Integrated Query) hinzugefügt, um Datenbanken mit Objekten und Methoden anstelle von Zeichenfolgen abzufragen.

Die meisten anderen Sprachen haben etwas Ähnliches mit unterschiedlichem Erfolg, abhängig von den Fähigkeiten dieser Sprache.

Andererseits ist es nützlich zu wissen, wie SQL funktioniert, und ich denke, es ist ein Fehler, sich vollständig davor zu schützen. Wenn Sie die Datenbank ohne nachzudenken verwenden, können Sie äußerst ineffiziente Abfragen schreiben und die Datenbank falsch indexieren. Sobald Sie jedoch die korrekte Verwendung von SQL verstanden und Ihre Datenbank optimiert haben, steht Ihnen ein sehr leistungsfähiges und erprobtes Werkzeug zur Verfügung, mit dem Sie die benötigten Daten extrem schnell finden können.

7
Mark Byers

Mein größter Grund für SQL ist das Ad-hoc-Reporting. Der Bericht, den Ihre Geschäftsbenutzer wünschen, weiß jedoch noch nicht, dass sie ihn noch benötigen.

4
blissapp

SQL ist eine allgemeine Schnittstelle, die von der DBMS-Plattform verwendet wird. Der gesamte Punkt der Schnittstelle besteht darin, dass alle Datenbankoperationen in SQL angegeben werden können, ohne dass zusätzliche API-Aufrufe erforderlich sind. Dies bedeutet, dass es eine gemeinsame Schnittstelle für alle Clients des Systems gibt - Anwendungssoftware, Berichte und Ad-hoc-Abfragetools.

Zweitens wird SQL immer nützlicher, da Abfragen komplexer werden. Verwenden Sie LINQ, um einen 12-Wege-Join mit drei Bedingungen anzugeben, die auf existentiellen Prädikaten basieren, und einer Bedingung, die auf einem Aggregat basiert, das in einer Unterabfrage berechnet wird. Dies ist in SQL ziemlich verständlich, in einem ORM jedoch unwahrscheinlich.

In vielen Fällen erfüllt ein ORM 95% dessen, was Sie möchten - die meisten von Anwendungen ausgegebenen Abfragen sind einfache CRUD-Vorgänge, die ein ORM oder andere generische Datenbankschnittstellenmechanismen problemlos verarbeiten können. Einige Vorgänge werden am besten mit benutzerdefiniertem SQL-Code ausgeführt.

ORMs sind jedoch nicht das A und O der Datenbankanbindung. Fowlers Muster der Unternehmensanwendungsarchitektur enthält einen guten Abschnitt über andere Arten von Datenbankzugriffsstrategien, wobei die jeweiligen Vorzüge besprochen werden. 

Es gibt oft gute Gründe, einen ORM nicht als primäre Datenbankschnittstellenschicht zu verwenden. Ein gutes Beispiel ist, dass Plattform-Datenbankbibliotheken wie ADO.Net oft genug gute Arbeit leisten und sich gut in die Umgebung integrieren. Sie werden vielleicht feststellen, dass der Nutzen durch die Verwendung einer anderen Schnittstelle die Vorteile der Integration nicht wirklich ausgleicht.

Der letzte Grund, aus dem Sie SQL nicht wirklich ignorieren können, ist jedoch, dass Sie letztendlich mit einer Datenbank arbeiten, wenn Sie eine Datenbankanwendung ausführen. Es gibt viele, viele WTF-Geschichten über Fehler im kommerziellen Anwendungscode, die von Personen gemacht wurden, die Datenbanken nicht richtig verstanden haben. Schlecht durchdachter Datenbank-Code kann in vielerlei Hinsicht zu Problemen führen, und wenn man bedenkt, dass man nicht verstehen muss, wie das DBMS funktioniert, ist dies ein Akt von Hubris, der eines Tages kommen und dich beißen muss. Schlimmer noch, es wird kommen und beißen einen anderen armen Schmoe, der Ihren Code erbt.

SQL ist eine Schnittstelle zwischen einem Menschen und eine Datenbank. Die Frage ist, warum wir müssen es für .__ verwenden. Anwendung/Datenbank-Interaktion? ICH Bitten Sie immer noch um Beispiele von Menschen SQL schreiben/debuggen.

Ich verwende sqlite häufig von einfachen Aufgaben (wie dem Protokollieren meiner Firewall-Protokolle direkt in einer sqlite-Datenbank) bis hin zu komplexeren Analyse- und Debugging-Aufgaben in meiner täglichen Forschung. Das Aufstellen meiner Daten in Tabellen und das Schreiben von SQL-Abfragen, um sie auf interessante Weise abzugrenzen, erscheint mir in diesen Situationen am natürlichsten. 

In Ihrem Punkt, warum es immer noch als Schnittstelle zwischen Anwendung/Datenbank verwendet wird, ist dies meine einfache Begründung:

  1. Es gibt ungefähr 3-4 Jahrzehnte __ seriöser Forschungen auf diesem Gebiet Beginnend 1970 mit Codds bahnbrechendem __. Papier über relationale Algebra Relationale Algebra bildet die mathematische Grundlage für SQL (und andere) QLs), obwohl SQL Nicht vollständig dem relationalen Modell folgt. 

  2. Die "Text" -Form der Sprache (Abgesehen davon, dass er leicht für Menschen verständlich ist.) ist auch leicht maschinenlesbar (zB mit einem Grammatik-Parser wie Lex) und mit beliebig vielen Optimierungen leicht in "Bytecode" umwandelbar. 

  3. Ich bin mir nicht sicher, ob ich das. Anderer Weg hätte ergeben überzeugende Vorteile in den generischen Fällen. Ansonsten ist es wäre wahrscheinlich entdeckt worden und in den 3 Jahrzehnten von .__ angenommen. Forschung. SQL liefert wahrscheinlich die beste Kompromisse bei der Überbrückung der Zwischen Menschen/Datenbanken und Anwendungen/Datenbanken.

Die Frage, die sich dann interessant stellt, lautet: "Was sind die wirklichen Vorteile, wenn Sie SQL auf andere Weise als" Nicht-Text "ausführen?" Werde jetzt google :)

3
neoblitz

Ich denke, die Prämisse der Frage ist falsch. Dass SQL als Text dargestellt werden kann, ist unerheblich. Die meisten modernen Datenbanken würden Abfragen nur einmal kompilieren und sie trotzdem zwischenspeichern, sodass Sie bereits einen "kompilierten Bytecode" haben. Und es gibt keinen Grund, warum das nicht klientenmäßig passieren konnte, obwohl ich nicht sicher bin, ob jemand es getan hat.

Sie sagten, SQL sei eine SMS-Nachricht. Ich denke an ihn als Boten und schießen Sie, wie wir wissen, nicht auf den Boten. Das eigentliche Problem ist, dass Beziehungen nicht gut genug sind, um Daten aus der realen Welt zu organisieren. SQL ist nur ein Lippenstift auf dem Schwein.

2
CurtainDog

Während ich Ihren Punkt sehe, hat die Abfragesprache von SQL einen Platz, vor allem in großen Anwendungen mit vielen Daten. Und um das Offensichtliche herauszustellen: Wenn die Sprache nicht vorhanden ist, können Sie sie nicht SQL (Structured Query Language) nennen. Der Vorteil von SQL gegenüber der von Ihnen beschriebenen Methode ist, dass SQL im Allgemeinen sehr gut lesbar ist, obwohl einige die Grenzen ihrer Abfragen wirklich stark erhöhen.

Ich stimme Mark Byers von ganzem Herzen zu, Sie sollten sich nicht vor SQL schützen. Jeder Entwickler kann SQL schreiben, aber damit Ihre Anwendung wirklich gut mit der SQL-Interaktion funktioniert, ist das Verstehen der Sprache ein Muss.

Wenn alles mit Bytecode vorkompiliert wurde, wie Sie es beschrieben haben, würde ich es hassen, die Anwendung debuggen zu müssen, nachdem der ursprüngliche Entwickler gegangen ist (oder sogar nachdem er den Code 6 Monate lang nicht gesehen hat).

2
Jeff Schumacher

Eines der Unix-Designprinzipien kann somit gesagt werden: "Schreiben Sie Programme, um Textströme zu handhaben, weil dies eine universelle Schnittstelle ist.".

Ich glaube, aus diesem Grund verwenden wir normalerweise SQL anstelle von 'Byte-SQL', das nur über eine Kompilierungsschnittstelle verfügt. Selbst wenn wir haben eine Byte-SQL haben, würde jemand eine "Text-SQL" schreiben, und die Schleife wäre abgeschlossen.

Auch MySQL und SQLite sind weniger voll funktionsfähig als beispielsweise MSSQL und Oracle SQL. Sie befinden sich also immer noch am unteren Ende des SQL-Pools.

1
Paul Nathan

Tatsächlich gibt es einige Nicht-SQL-Datenbanken (wie Objectivity, Oracle Berkeley DB usw.), die jedoch nicht erfolgreich waren. Wenn jemand in der Zukunft eine intuitive Alternative für SQL findet, wird Ihre Frage beantwortet.

1

SQL wurde erstellt, um eine Schnittstelle für Ad-hoc-Abfragen in einer relationalen Datenbank bereitzustellen.

Im Allgemeinen verstehen die meisten relationalen Datenbanken irgendeine Form von SQL.

Es gibt objektorientierte Datenbanken, die (vermutlich) Objekte für ihre Abfrage verwenden ... aber, wie ich es verstehe, haben OO -Datenbanken viel mehr mitgehört und relationale Datenbanken funktionieren einwandfrei.

Mit relationalen Datenbanken können Sie auch im Zustand "nicht verbunden" arbeiten. Sobald Sie die gewünschten Informationen erhalten haben, können Sie die Datenbankverbindung schließen. Bei einer OO -Datenbank müssen Sie entweder alle Objekte zurückgeben, die sich auf das aktuelle Objekt beziehen (und die Objekte, auf die sie sich beziehen ... und die ... etc ...) oder die Verbindung erneut öffnen, um neue Objekte abzurufen Objekte, wenn auf sie zugegriffen wird.

Neben SQL verfügen Sie auch über ORMs (objektrelationale Zuordnungen), die Objekte SQL und zurück zuordnen. Es gibt einige von ihnen, darunter LINQ (.NET), MS Entity Framework (.NET), Hibernate (Java), SQLAlchemy (Python), ActiveRecord (Ruby), Klasse :: DBI (Perl) usw. .

1
Powerlord

Wenn Sie sich im ersten Teil auf die scheinbar objektbezogene Mapping-Impedanz beziehen, scheint es. Es gibt bereits viele Rahmenbedingungen, um dieses Problem zu lösen. Es gibt auch Tradeofs. Einige Dinge werden einfacher, andere werden komplexer, im Allgemeinen funktionieren sie jedoch gut, wenn Sie sich die zusätzliche Schicht leisten können.

Im zweiten Teil scheinen Sie sich zu beschweren, dass SQL Text ist (es werden Zeichenfolgen anstelle von IDs usw. verwendet) ... SQL ist eine Abfragesprache . Jede Sprache (Computer oder sonstiges), die von Menschen gelesen oder geschrieben werden soll, ist für diese Angelegenheit textorientiert. Assembly, C, PHP, nennen Sie es. Warum? Nun ja ... es macht Sinn, nicht wahr?

Wenn Sie vorkompilierte Abfragen wünschen, haben Sie bereits gespeicherte Prozeduren. Vorbereitete Anweisungen werden auch im laufenden Betrieb (IIRC) erstellt. Die meisten (wenn nicht alle) Datenbank-Treiber sprechen ohnehin über ein Binärprotokoll mit dem Datenbankserver. 

1

ja, Text ist etwas ineffizient. Tatsächlich ist das Abrufen der Daten jedoch viel kostspieliger, so dass der textbasierte SQL-Server relativ unbedeutend ist.

1
Keith Nicholas

Eine Datenbanksprache ist nützlich, da sie ein logisches Modell für Ihre Daten bereitstellt, unabhängig von den Anwendungen, die sie verwenden. SQL hat jedoch eine Reihe von Nachteilen, nicht zuletzt weil die Integration mit anderen Sprachen schlecht ist. Die Unterstützung für Typen liegt etwa 30 Jahre hinter dem Rest der Branche und war ohnehin nie eine wirklich relationale Sprache.

SQL hat sich vor allem durchgesetzt, weil der Datenbankmarkt von den drei großen Anbietern dominiert wurde und ist, die ein großes Interesse daran haben, ihre Investitionen zu schützen. Das ändert sich und die Tage von SQL sind wahrscheinlich nummeriert, aber das Modell, das es endgültig ersetzen wird, ist wahrscheinlich noch nicht eingetroffen - obwohl es heutzutage viele Konkurrenten gibt.

1
nvogel

Ich glaube nicht, dass die meisten Leute Ihre Frage bekommen, obwohl ich denke, dass dies sehr klar ist. Leider habe ich keine "richtige" Antwort. Ich würde vermuten, dass es eine Kombination mehrerer Dinge ist:

  1. Halb willkürliche Entscheidungen, wenn sie so konzipiert wurden, wie einfache Bedienung, kein SQL-Compiler (oder IDE), Portabilität usw.
  2. Es kam gut durch (wahrscheinlich aus ähnlichen Gründen)
  3. Und jetzt wird aus historischen Gründen (Kompatibilität, bekannt, bewährt usw.) weiterhin Gebrauch gemacht.
  4. Ich glaube nicht, dass sich die meisten Unternehmen mit einer anderen Lösung befasst haben, weil sie gut funktioniert, kein Engpass ist, sondern ein Standard, bla, bla.
1

Denn oft können Sie nicht sicher sein, dass (Sie zitiert werden) "niemand je nach der Bereitstellung" . Das Wissen, dass es eine einfache Schnittstelle für das Reporting und das Abfragen von Datensätze gibt, ist ein guter Weg für die Weiterentwicklung Ihrer App.
Sie haben Recht, dass es andere Lösungen gibt, die in bestimmten Situationen gültig sein können: XML, Nur-Text-Dateien, OODB ...
Eine Reihe gemeinsamer Schnittstellen (wie ODBC) ist jedoch ein großer Vorteil für die Lebensdauer von Daten.

0
Patrick Honorez

Es gibt viele nicht relationale Datenbanksysteme. Hier nur einige davon: MemcachedTokyo Cabinet

0
Jay

Ich denke, der Grund könnte die Search/Find/Grab-Algorithmen sein, mit denen die SQL-Laungage verbunden ist. Denken Sie daran, dass SQL seit 40 Jahren entwickelt wurde - und das Ziel war sowohl präformistisch als auch benutzerfreundlich.

Fragen Sie sich, was der beste Weg ist, um 2 Plätze zu finden. Warum sollten Sie das jedes Mal untersuchen, wenn Sie etwas tun möchten, das jedes Mal umfasst, wenn Sie Ihre Anwendung entwickeln? Angenommen, das Hauptziel ist die Entwicklung Ihrer Anwendung, wenn Sie eine Anwendung entwickeln.

Eine Anwendung hat Ähnlichkeiten mit anderen Anwendungen, eine Datenbank hat Ähnlichkeiten mit anderen Datenbanken. Daher sollte es einen "besten Weg" dafür geben, logisch zu interagieren.

Fragen Sie sich auch, wie Sie eine bessere Konsole-Anwendung entwickeln, die keine SQL-Laungage verwendet. Wenn Sie das nicht können, denke ich, müssen Sie eine neue Art von GUI entwickeln, die noch einfacher zu bedienen ist als mit einer Konsole - um daraus Dinge zu entwickeln. Und das könnte tatsächlich möglich sein. Die meisten Anwendungsentwicklungen basieren jedoch immer noch auf Konsole und Typisierung.

Wenn es ums Laungage geht, glaube ich nicht, dass Sie eine wesentlich einfachere Textsprache als SQL machen können. Und denken Sie daran, dass jedes Wort von irgendetwas untrennbar mit seiner Bedeutung zusammenhängt - wenn Sie die Bedeutung entfernen, kann das Wort nicht verwendet werden -, wenn Sie das Wort entfernen, können Sie die Bedeutung nicht kommunizieren. Sie haben nichts, was Sie damit beschreiben könnten (und vielleicht denken Sie nicht einmal, dass es mit nichts anderem in Verbindung steht, was Sie zuvor gedacht haben ...).

Grundsätzlich werden den Wörtern also die bestmöglichen Algorithmen für die Datenbankmanipulation zugewiesen. Wenn Sie diese Wörter entfernen, müssen Sie diesen Manipulationen etwas anderes zuweisen - und was wäre das?

0
Lealo

Was die Suche nach einer relationalen Datenbank angeht, die SQL nicht als primäre Schnittstelle verwendet, werden Sie sie wahrscheinlich nicht finden. Grund: SQL ist eine großartige Möglichkeit, über Beziehungen zu sprechen. Ich kann nicht verstehen, warum Ihnen das so wichtig ist: Wenn Sie SQL nicht mögen, legen Sie eine Abstraktion darüber (wie bei einem ORM), damit Sie sich darüber keine Sorgen machen müssen. Lassen Sie die Abstraktion sich darum kümmern. Es bringt Sie an den gleichen Ort.

Das Problem, das Sie hier wirklich erwähnen, ist die Trennung von Objekt und Beziehung - das Problem liegt in der Beziehung selbst. Objekte und relationale Tupel sind nicht immer eine 1: 1-Beziehung, weshalb ein Entwickler mit einer Datenbank frustriert sein kann. Die Lösung besteht darin, einen anderen Datenbanktyp zu verwenden.

0
J. Polfer