Warum kann man nicht sehen, wie Datenbankmanagementsysteme Ergebnisse ermitteln?

vram78

Lieutenant
Registriert
Dez. 2015
Beiträge
717
Guten Abend,

Ich bin gerade dabei, Java von Grund auf neu zu erlernen und bin auf folgende Textpassage gestoßen:
Konkret geht es mir um diesen Satz hier: ,,denn wie das Datenbankmanagementsystem zu unserer Abfrage die Ergebnisse ermittelt, müssen und können wir weder vorgeben noch sehen." Was genau meint der Autor damit?

Außerdem verstehe ich nicht, was der Autor damit meint, dass jene Befehlsform für Programmiersprachen gar nicht selbstverständlich ist. Welche Befehlsform? Meint der Autor etwa den imperativen Sprachkonzept?


1607897542922.png
 
vram78 schrieb:
Konkret geht es mir um diesen Satz hier: ,,denn wie das Datenbankmanagementsystem zu unserer Abfrage die Ergebnisse ermittelt, müssen und können wir weder vorgeben noch sehen." Was genau meint der Autor damit?
Mit einer SQL-Abfrage (in SQL) definierst du welche Daten du haben möchtest, aber nicht wie die Datenbank die Daten aus der Datenbank holt. Das bleibt völlig der Datenbank überlassen ohne, dass du dich darum kümmenr musst.
 
KitKat::new() schrieb:
ohne, dass du dich darum kümmenr musst.
Achso. Warum aber schreibt der Autor, dass man die Möglichkeit nicht dazu hat, einzusehen, wie die Datenbank das eben macht? Wäre ja für einen Entwickler ziemlich interessant einzusehen.
 
"Diese Befehlsfirm ist fuer Imperative Priogrammiersprachen garnicht selbstverstaendlich" haette ich noch durchgehen lassen.

Die Abfrage wird halt weg abstrahiert um unnoetige Komplexitaet zu vermeiden. So ist es dir egal welches Datenbanksystem zum Einsatz kommt.

Installier dir mal mariaDB, leg eine Datenbank an, leg ein paar tabellen rein und schau dir SQL an. Schwierig sit das alles trotzdem nicht :)
 
Stell dir die Datenbank wie einen Webserver vor, mit dem du kommunizierst. Du sagst dem Webserver zB was für Daten du haben willst. Der Webserver liefert dir diese Daten (zB eine Webseite als HTML). Wie der Server diese Seite aber generiert, siehst du nicht. Der HTML-Code kann vordefiniert als Dokument vorliegen, der Server kann aber das HTML auch on-the-fly über Programmierung generieren.
 
vram78 schrieb:
Achso. Warum aber schreibt der Autor, dass man die Möglichkeit nicht dazu hat, einzusehen, wie die Datenbank das eben macht? Wäre ja für einen Entwickler ziemlich interessant einzusehen.
Kann man halt auch. Nur anscheinend nicht in java direkt. Da muss man halt paper und Lehrbuecher lesen & mit Datenbanken spielen.
Die Formulierungen sind nicht immer 100% richtig in dem buch. Nach seiner definition ist Prolog fuer mich keine Sprache.

Muss vielleicht nochmal ueberdenken was ich den Ersties naechste Woche in der Vorlesung sage
 
@KitKat::new()
Ich bin recht muede, aber da steht doch, wenigstens Sinngemaess, Diese befehlsform ist fuer Programmiersprachen nicht selbstverstaendlich, da es Sprachen gibt, die zu einem Problem selbststaendig eine Loesung finden. Ein Beispiel dafuer ist Prolog.

Die Aussage ueber Prolog ist korrekt, aber fuer mich ist Prolog in dem Satz, in der gegebenen Formulierung keine Programmiersprache mehr.

@vram78 Klar, ist aber ein wenig wirr :): Fertig Studieren(^TM), hier auch als Wissenschaftliche Hilfskraft arbeiten und nebenher viel freiberuflich und bei 2 Firmen mit relativ festen Vertraegen, bei denen ich schon vor dem Studium war. hauptsache es macht Spass.
 
SQL DBMs können dir sehr wohl einen Abfrageplan ausgeben, der dir zeigt, wie das System zur Lösung kommt.
Ab und an muss man das auch tun. Weniger weil es interessant ist, sondern weil man dahinter kommen muss, warum seine Abfrage so langsam läuft.
Ansonsten ist es wie mit jeder anderen Bibliothek / Applikation auch: Ist sie open source, kannst du dir natürlich alles anschauen. Wenn nicht, ist es eine Blackbox, außer sie gibt dir explizit irgendwas aus (wie eben Abfragepläne).
 
  • Gefällt mir
Reaktionen: DerTiger
Vielleicht ist damit gemeint, daß man in SQL eben nicht, wie in anderen Programmiersprachen, Debuggen und in die Speicherbereiche von Stack und Co. reinschauen kann.
 
Man sollte sich auf jeden Fall mal solche Ausführungspläne angucken damit man sieht, was so ein DBMS unter der Haube alles so macht. Und Mal einen Artikel über die zugrunde liegenden Daten Strukturen lesen.
Sonst bleibt das Verständnis doch Recht abstrakt und man weiß SQL gar nicht zu schätzen :D.
Ich hab es damals jedenfalls nicht verstanden als ich das mit 4th Generation Language und so lernte.
 
vram78 schrieb:
Achso. Warum aber schreibt der Autor, dass man die Möglichkeit nicht dazu hat, einzusehen, wie die Datenbank das eben macht? Wäre ja für einen Entwickler ziemlich interessant einzusehen.
Wie schon weiter oben angemerkt, das Buch ist da nicht ganz korrekt oder zumindest irreführend. Man kann durchaus einsehen was die Datenbanken da so machen, man muss sie aber halt direkt fragen. In Postgres ist das z.B. der "EXPLAIN ANALYZE" Befehl.

Eine Besonderheit ist das es nicht nur von der SQL Query selbst abhängt wie die Datenbank die Anfrage bearbeitet, sondern auch von den Parametern und dem gesamten Inhalt der Datenbank. Die Datenbank hat Statistiken über die Daten und benutzt diese um einen möglichst guten Plan zu erstellen um diese Daten abzufragen. Wenn man also nur eine SQL Query alleine hat kann man nicht unbedingt vorhersagen wie die Datenbank diese tatsächlich ausführt.

Wenn man ernsthaft mit Datenbanken arbeitet, ist es auch wichtig diese Aspekte zu verstehen. Wenn man nicht versteht was die Datenbank da macht, kann es schwierig sein gute Performance rauszuholen. Wenn ich eine SQL Query schreibe habe ich meistens eine Vorstellung wie die Datenbank diese umsetzten wird. Die Datenbank ist da zwar manchmal anderer Meinung als ich, aber ein gewisses Grundverständnis ist hier trotzdem sehr hilfreich um grob ineffiziente Anfragen zu vermeiden.
 
  • Gefällt mir
Reaktionen: Oelepoeto, DerTiger und BeBur
Formulierungen hier sind denke ich ungünstig. Man kann reinsehen. Viele interessiert es nicht. Die Abfrage sagt in der einfachsten Form gib mir X, egal wie du das machst. Allerdings gibt es wie erwähnt EXPLAIN PLANs, die einen zeigen, was das RDBMS vorhat zu machen und auch Tracing und co. um hinterher zu schauen, was es wirklich gemacht hat.

Genauso gibt es mehrere Möglichkeiten darauf Einfluss zu nehmen, sei es durch Anlage von Indizes, anderen Aufbau der Abfrage z.B. mit der WITH-Clause oder entsprechenden Hints, wie es sie z.B. bei Oracle gibt, wo ich sagen kann welcher Index genutzt werden soll, ob erst die ersten X Zeilen geladen werden sollen etc. pp.
 
Die Formulierung ist leicht verunfallt, was fast immer passiert, wenn man mit allgemeinverständlicher Sprache komplexe Fachthemen umschreiben will. Was der Autor andeuten will ist, dass es verschiedene Paradigmen beim Programmieren gibt und verschiedene Programmiersprachen sich daran orientieren. Es ist ganz hilfreich zu wissen, dass es da unterschiedliche Konzepte und damit verbundene Sprachen gibt, um im richtigem Moment das richtige Werkzeug suchen und wählen zu können.

Lektüre dazu: https://en.wikipedia.org/wiki/Programming_paradigm
 
floq0r schrieb:
und das war noch nie eine gute Idee :D
Ajo meist repariert man Probleme, die eigentlich an anderer Stelle entstehen. Statistiken die grob über die ganze Datenbank laufen mit einigen Tabellen, die mal leer sind und mal prall gefüllt usw. Ist eben meist eher ein Workaround. Habe ich aber dahin gehend schon einige Male benötigt.

Vermutlich gibt es sowas auch oft, wenn Entwickler und DBA verschiedene Personen, Abteilungen oder gar Geschäftsstellen sind. Da gibt es für sowas dann ein Ticket aber der Kunde kann im Zweifel nicht arbeiten, ergo muss eine Lösung her.

Aber klar stumpfes Reinkopieren sollte es nicht sein. Wenn man das Schema aber entsprechend versteht, sehe ich das nicht so als Problem. Leider ist natürlich Erstes auch häufig zu finden, quasi fix von Stackoverflow mal einen Hint überall reinkopieren, weil er in einer Abfrage aktuell bessere Ergebnisse liefert.
 
  • Gefällt mir
Reaktionen: floq0r
Zurück
Oben