speicher..legen länger?
> >
> > In meiner IT-Frühzeit, wusste man noch, dass es verschiedene
> > Datenbankparadigmen gibt: Netzwerk-BDs, hierarchische und
> > relationale. Letztere haben dabei den großen Nachteil, dass sie (a)
> > keine Strukturinformationen in der datenbank haben (heute nicht mehr
> > ganz richtig)
>
> Seit eh und je ist ein Katalog Bestandteil einer relationalen
> Datenbank, und der enthält alle Strukturinformationen.
Hier muss ich Dir leider widersprechen. Für die sogen. RDBMS trifft
das vollumfänglich zu. Leider sind aber auch Produkte wie dBase,
Foxpro, MS Access, MySQL u.v.a.m zu den relationalen Datenbanken,
wenn auch nicht zu den Client/Server basierten Systemen sondern eher
zu den File-Server-basierten Systemen zu rechnen. Keine der genannten
hat seit jeher einen Katalog. IBMs erste Referenzimplementierung RDB
und die Nachfolger bis hin zum DB/2 allerdings haben seit jeher einen
Catalog.
> > und dass (b) die Verknüpfung der Daten zur Laufzeit
> > sehr aufwändig ist.
>
> Das trifft zwar auf die derzeitigen Implementierungen zu, ist aber
> kein Problem des relationalen Modells. Nichts hindert ein RDBMS
> daran, Sätze in Tabellen, die oft gejoint werden, intern mit
> Datenbank-Pointern zu verknüpfen.
Das passende Gegenargument an dieser Stelle lautet wohl eher:
In RDBMS ist es wenigstens möglich eine valide und validierte
Verknüpfung der Daten zur Laufzeit durch datenbank eigene Mechanismen
herzustellen. Das Problem von Objektdatenbanken, wie auch von
XML-Datenbanken ist doch, dass die Validität von Objektreferenzen
nicht sichergestellt werden kann. Schon alleine deshalb nicht, weil
Objektdatenbanken kein beweisbares mathemathisches Modell zu grunde
liegt. Das aber ist mit der Mengenlehre bei den RDBMS grundsätzlich
anders.
> Auch kann ein RDBMS eine interne Denormalisierung durchführen.
> Leider können die heutigen DBMS das nicht. Die Folge ist, dass man
> beim Datenbankdesign der Performance wegen eine Denormalisierung
> macht und sich damit dann Probleme mit der Datenintegrität
> einhandelt.
Das die heutigen RDBMS keine interne Denormalisierung der Daten
durchführne können ist (so wie ich die behauptung vom Lesen her
verstehe) schlicht und einfach “Unsinn”. Man schaue sich nur z.B.
Oracles Materialized Vews an.
> > Für viele Anwendungen sind RDBMS nicht geeignet, da sie jedoch gut
> > auf die “klassischen” Datenbankanwendungen passen, haben sie sich so
> > weit durchgesetzt, dass heute jeder mit “Datenbak” “relationale
> > Datenbank” meint. Bei der Persistenz von Objekt- und XML-Strukturen
> > kommen aber alte Bekannte wieder zum Vorschein: ein OODBMS ist
> > nämlich nichts weiter, als eine Netwerk-DB mit speziellen
> > Mapping-Mechanismen, eine XML-DB ist eine hierarchiche DB.
> >
>
> Was sich zur Zeit abspielt, ist schon ziemlich verrückt:
>
> Der so ziemlich einzige Vorteil von XML (wenn es um Daten und nicht
> um Dokumente geht) ist, dass es ein Format ist, auf das sich die
> verschiedenen Hersteller einigen konnten.
>
> Weil nun Daten im - wie zu Recht bemerkt - hierarchischen XML-Format
> ausgetauscht werden, sollen sie nun plötzlich wieder hierarchisch
> gespeichert werden und wir sind was Datenmodelle betrifft wieder in
> den 50ern angelangt.
>
> Da aber das hierarchische Modell schon früher nicht vernünftig
> funktioniert hat, wird den XML-Datenbanken nach meiner Einschätzung
> auch kein Erfolg beschieden sein. Allen Daten eine Hierarchie
> überzustülpen und die übrigen Beziehungen mit Refernzen auszudrücken
> ist nun mal kein brauchbarer Ansatz zur Datenmodellierung.
full ack. Oder wie Date zu sagen pflegte, wer das relationale Modell
verstanden hat, weiß, dass Objektdatenbanken überflüssig sind.
masltov