1
Wo liegen die Unterschiede zwischen mengenorientierten und navigationsorientierten Datenbankabfragen?
Hallo,
wie der Ttel schon aussagt, interessiert es mich, wo genau die Unterschiede zwischen mengenorientierten und navigationsorientierten Datenbankabfragen liegen.
Bisher dachte ich, dass Entwickler in ihre Applikationen einfach die SQL-Statements direkt einprogrammieren.
Beispielsweise so:
SLECT AdrNr, Name, PLZ, Ort
FROM ADRESSEN
WHERE Land = 'Deutschland'
ORDER BY AdrNr
Das Datenbankmanagementsystem erhält das SQL-Statement und liefert die entsprechenden Werte an die Applikation zurück. Was heißt es jetzt in der Praxis,
wenn man von navigationsorientierten Datenbankabfragen spricht? Programmiert man die Abfrage dann nicht mehr in SQL? Hat das eventuell etwas mit ISAM (Index Sequential Access Method) zutun?
Unter http://de.wikipedia.org/wiki/Index_Sequential_Access_Method kann man nachlesen, dass ISAM eine entwickelte Zugriffsmethode für Datensätze einer Datei von IBM ist. Leider konnte ich weitergehende
informationen zu diesem Thema nicht finden.
Über Antworten und Links/Verweise zur weiterführenden Literatur (gerne auch in Englisch) bin ich Euch sehr dankbar.
Gruß
Mavico
wie der Ttel schon aussagt, interessiert es mich, wo genau die Unterschiede zwischen mengenorientierten und navigationsorientierten Datenbankabfragen liegen.
Bisher dachte ich, dass Entwickler in ihre Applikationen einfach die SQL-Statements direkt einprogrammieren.
Beispielsweise so:
SLECT AdrNr, Name, PLZ, Ort
FROM ADRESSEN
WHERE Land = 'Deutschland'
ORDER BY AdrNr
Das Datenbankmanagementsystem erhält das SQL-Statement und liefert die entsprechenden Werte an die Applikation zurück. Was heißt es jetzt in der Praxis,
wenn man von navigationsorientierten Datenbankabfragen spricht? Programmiert man die Abfrage dann nicht mehr in SQL? Hat das eventuell etwas mit ISAM (Index Sequential Access Method) zutun?
Unter http://de.wikipedia.org/wiki/Index_Sequential_Access_Method kann man nachlesen, dass ISAM eine entwickelte Zugriffsmethode für Datensätze einer Datei von IBM ist. Leider konnte ich weitergehende
informationen zu diesem Thema nicht finden.
Über Antworten und Links/Verweise zur weiterführenden Literatur (gerne auch in Englisch) bin ich Euch sehr dankbar.
Gruß
Mavico
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 169453
Url: https://administrator.de/forum/wo-liegen-die-unterschiede-zwischen-mengenorientierten-und-navigationsorientierten-datenbankabfragen-169453.html
Ausgedruckt am: 24.12.2024 um 13:12 Uhr
1 Kommentar
Moin Mavico,
"mengenorientierte" und "navigationsorientierte" Abfragen gibt es so in ausschliesslicher Reinform nicht - beides sind Designentscheidungen, die auch in "relationalen DBMSen" an bestimmten Stellen umgesetzt werden (können).
Der historische Klassiker ist in der Tat die ISAM, einfacher und durchaus genialer Grundgedanke dabei: Wenn ich logisch unahängige Teile des Gesamtdatenbestandes in einzelnen (physikailsch getrennten) Segmenten ablege, dann brauche ich im einzelnen Segment die Information, was dieses Segment enthält, NICHT mehr in jedem einzelnen Datesatz zu speichern.
Weniger abstrakt am Beispiel deines ADRESSEN-Statements oben:
Wenn wir uns diese Abfrage anschauen, dann wäre doch eine Argumentation:
"Hey, DIESE Abfrage macht ja dann Sinn, wenn im Fall "Land=Deutschland" ein 5-stelliges Feld "PLZ" abgefragt wird.
Macht denn diese Abfrage auf dieselbe Tabelle mit denselben Feldern auch Sinn, wenn das Land Brasilien, Ghana oder die Mongolei ist?
Gibt es da 5stellige Postleitzahlen? Wohl kaum. Warum dann also EINE Adresstabelle für alle Länder?"
Ebenfalls ein gutes Beispiel wäre eine Adresstabelle, die vielleicht für das Land "Deutschland" ein Feld "Bundesland" enthalten kann, aber bei Land =Schweiz sinnvoller ein Feld "Kanton" enthalten müsste, bei anderen Staaten dagegen vielleicht "Department" oder "Bezirk".
Wenn also im Fall "Land =Deutschland" ein separates physikalisches Segment (oder eine eigene Tabelle) abgefragt werden würde, dann braucht dieses "Segment" natürlich nicht mehr ein Feld "LAND" mit dem Wert "Deutschland" enthalten - und auch das "WHERE Land='Deutschland'" ist überflüssig.
Nachteil - eine Gesamtabfrage uber die "ADRESSEN" aus Deutschland, Ghana und der Mongolei wäre viel aufwändiger - die sind ja nicht nur physikalisch eigene Tabellen, sondern können auch ziemlich schnell unterschiedliche Strukturen, Felder und Feldlängen haben.
Und der größte Nachteil - natürlich kann es die "gleichen" Datensätze, zum Beispiel das "gleiche" Feld "AdrNr" mit dem Wert 4711 in mehreren "Segmenten" geben -why not.
Nichtsdestotrotz - "navigationsorientiertes Design" bleibt nicht aus in einer Frontend-Welt, die sehr oft von java-üblichen Hierarchie-Baumstrukturen geprägt ist. Wenn du bei einer beliebigen Registrierungsmaske für eine Evaluationssoftware die Standardfelder ausfüllst, dann siehst du genau dieses Konzept.
Du wirst ziemlich früh nach einem Heimatland gefragt - nach Eingabe von "Germany" geht es mit einer Unterabfrage nach den einzeln aufgeführten 16 "Bundesländern" weiter. Im Fall "Land=United States" kommen die Zipcodes der 50 Staaten. Einzelne Segmente, physikalisch unabhängig.
Nachteil - die Detailtabelle "Bundesländer" oder "Postalcode" trägt eben keine Information darüber, dass die Daten nur noch im Kontext "Deutschland" oder "United States" einen Sinn ergeben. Der Entwickler muss eben die richtigen Tabellen miteinander verknüpfen - eine Verknüpfung über mehrere gemeinsame Felder ist in der Regel nicht mehr möglich. Und eine "programmunabhängige Lesbarkeit/Interpretierbarkeit der Daten" ist de facto nicht mehr gegeben - ohne das Kopfwissen der Entwickler "Wenn Land=Deutschland, dann benutze Tabelle Bundesländer" oder eine penible Dokumention hast du verratzt, wenn du nur die Tabelleninhalte siehst.
Grüße
Biber
"mengenorientierte" und "navigationsorientierte" Abfragen gibt es so in ausschliesslicher Reinform nicht - beides sind Designentscheidungen, die auch in "relationalen DBMSen" an bestimmten Stellen umgesetzt werden (können).
Der historische Klassiker ist in der Tat die ISAM, einfacher und durchaus genialer Grundgedanke dabei: Wenn ich logisch unahängige Teile des Gesamtdatenbestandes in einzelnen (physikailsch getrennten) Segmenten ablege, dann brauche ich im einzelnen Segment die Information, was dieses Segment enthält, NICHT mehr in jedem einzelnen Datesatz zu speichern.
Weniger abstrakt am Beispiel deines ADRESSEN-Statements oben:
SELECT AdrNr, Name, PLZ, Ort
FROM ADRESSEN
WHERE Land = 'Deutschland'
ORDER BY AdrNrWenn wir uns diese Abfrage anschauen, dann wäre doch eine Argumentation:
"Hey, DIESE Abfrage macht ja dann Sinn, wenn im Fall "Land=Deutschland" ein 5-stelliges Feld "PLZ" abgefragt wird.
Macht denn diese Abfrage auf dieselbe Tabelle mit denselben Feldern auch Sinn, wenn das Land Brasilien, Ghana oder die Mongolei ist?
Gibt es da 5stellige Postleitzahlen? Wohl kaum. Warum dann also EINE Adresstabelle für alle Länder?"
Ebenfalls ein gutes Beispiel wäre eine Adresstabelle, die vielleicht für das Land "Deutschland" ein Feld "Bundesland" enthalten kann, aber bei Land =Schweiz sinnvoller ein Feld "Kanton" enthalten müsste, bei anderen Staaten dagegen vielleicht "Department" oder "Bezirk".
Wenn also im Fall "Land =Deutschland" ein separates physikalisches Segment (oder eine eigene Tabelle) abgefragt werden würde, dann braucht dieses "Segment" natürlich nicht mehr ein Feld "LAND" mit dem Wert "Deutschland" enthalten - und auch das "WHERE Land='Deutschland'" ist überflüssig.
Nachteil - eine Gesamtabfrage uber die "ADRESSEN" aus Deutschland, Ghana und der Mongolei wäre viel aufwändiger - die sind ja nicht nur physikalisch eigene Tabellen, sondern können auch ziemlich schnell unterschiedliche Strukturen, Felder und Feldlängen haben.
Und der größte Nachteil - natürlich kann es die "gleichen" Datensätze, zum Beispiel das "gleiche" Feld "AdrNr" mit dem Wert 4711 in mehreren "Segmenten" geben -why not.
Nichtsdestotrotz - "navigationsorientiertes Design" bleibt nicht aus in einer Frontend-Welt, die sehr oft von java-üblichen Hierarchie-Baumstrukturen geprägt ist. Wenn du bei einer beliebigen Registrierungsmaske für eine Evaluationssoftware die Standardfelder ausfüllst, dann siehst du genau dieses Konzept.
Du wirst ziemlich früh nach einem Heimatland gefragt - nach Eingabe von "Germany" geht es mit einer Unterabfrage nach den einzeln aufgeführten 16 "Bundesländern" weiter. Im Fall "Land=United States" kommen die Zipcodes der 50 Staaten. Einzelne Segmente, physikalisch unabhängig.
Nachteil - die Detailtabelle "Bundesländer" oder "Postalcode" trägt eben keine Information darüber, dass die Daten nur noch im Kontext "Deutschland" oder "United States" einen Sinn ergeben. Der Entwickler muss eben die richtigen Tabellen miteinander verknüpfen - eine Verknüpfung über mehrere gemeinsame Felder ist in der Regel nicht mehr möglich. Und eine "programmunabhängige Lesbarkeit/Interpretierbarkeit der Daten" ist de facto nicht mehr gegeben - ohne das Kopfwissen der Entwickler "Wenn Land=Deutschland, dann benutze Tabelle Bundesländer" oder eine penible Dokumention hast du verratzt, wenn du nur die Tabelleninhalte siehst.
Grüße
Biber
