Objektorientierte Datenbank

blurry333

Hallo ,

ich versteh den Unterschied zu einer Tabellenförmigen/Relationalen Datenbank noch nicht richtig. Im Speicher liegen die Daten doch auch zeilenweise drin oder ?

Vorname | Nachname | Strasse | Wohnort

Es gäbe jetzt wohl ein Objekt Anschrift .

z.B. so

class Anschrift
{

string Vorname[] ;
string Nachname[];
string Strasse [] ;
string Wohnort[] ;
};

hustbaer

In einer objektorientierten Datenbank definierst du normalerweise nicht pro Klasse einen Table - es geht gerade darum genau das zu vermeiden.

Weiters musst du dich auch nicht darum kümmern wie Verweise auf andere Objekte dargestellt werden, das OODBMS übernimmt das für dich.

blurry333

hustbaer schrieb:

es geht gerade darum genau das zu vermeiden.

Was beim relationalen Konzept gut sein soll, will man da vermeiden. Wieso das denn ?

hustbaer

Weil es eben nicht immer gut ist, z.B. wenn Vererbung ins Spiel kommt.

Wenn du sowas mal in einer relationalen Datenbank abgebildet hast, dann weisst du wieso es nicht gut ist.

Bzw. ich kann's dir auch sagen: es skaliert scheisse schlecht. Abfragen sind dadurch schnell mal um ein Vielfaches langsamer als wenn man alle Spalten in einen einzigen Table wirft. Was dann aber auch wieder schlecht ist, weil der Table irre breit wird (=unübersichtlich). Und weil man kaum mehr sinnvoll Constraints auf die Felder setzen kann. Alle Felder bis auf die der ersten Basisklasse müssen dann nullable sein, was aber wieder doof ist, wenn die Felder für Objekte eines bestimmten Typs eben nicht NULL sein dürfen.

Natürlich kann man auch pro konkretem Typ eine Tabelle machen, die alle Felder enthält, inklusive der von der Basisklasse geerbten Felder. Das ist aber wieder doof, weil man dann in vielen verschiedenen Tables suchen muss, wenn man ein Objekt sucht vom dem man nur den Primary-Key und die Basisklasse kennt, nicht aber den konkreten Typ.

Ein weiterer Punkt: beim Programmieren hat man oft mal Objekte deren Daten Listen oder z.T. sogar Baumartige Strukturen enthalten. In einer Tabellenbasierten DB lässt sich sowas kaum sinnvoll abbilden. Listen gehen natürlich noch mit Detail-Tables. Ist aber lästig in der Handhabung, und z.T. sind Detail-Tables auch nicht optimal was die Performance angeht.
Baumartige Strukturen sind natürlich theoretisch auch mit Tabellen abbildbar, aber was Handhabung und Performance angeht noch schlimmer als einfache Listen.

Einige RDBMS bieten als Mittelweg auch Dinge wie z.B. XML Spalten an. Auf diese kann man dann spezielle XML-Indexe definieren, in denen man dann mehr oder weniger performant mit XPath/XQuery suchen kann.