Maximale Anzahl Tabellen in Datenbank
Markus Deckmann
nachdem ich heute Nacht ï¿œber 2 Stunden nach der Antwort auf meine Frage
gesucht habe nun die Fragestellung hier:
Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
Bei meinen Recherchen habe ich leider zwischen ca. 60, ï¿œber 60.000 bis
hin zu 4 Milliarden alles gefunden.
Ciao Markus
Niels Braczek
> nachdem ich heute Nacht über 2 Stunden nach der Antwort auf meine Frage
> gesucht habe nun die Fragestellung hier:
>
> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
Offensichtlich liegt eine evtl. Begrenzung nicht innerhalb von MySQL,
denn sonst wäre das hier aufgeführt:
http://dev.mysql.com/doc/refman/5.1/en/limits.html
> Bei meinen Recherchen habe ich leider zwischen ca. 60, über 60.000 bis
> hin zu 4 Milliarden alles gefunden.
Wenn es eine Grenze gibt, ist die wohl durch das Betriebs- bzw.
Dateisystem vorgegeben (max. Anzahl Dateien in einem Verzeichnis).
MfG
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Markus Deckmann
>> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
> Offensichtlich liegt eine evtl. Begrenzung nicht innerhalb von MySQL,
> denn sonst wäre das hier aufgeführt:
> http://dev.mysql.com/doc/refman/5.1/en/limits.html
Das hatte ich wohl in der deutschen Doku übersehen. Hätte vielleicht mal
auf Englisch schauen sollen. Allerdings schießt es in meinem Fall u.U.
das Limit auf 61 Tabellen innerhalb eines JOINS das ich MySQL nutzen kann.
>> Bei meinen Recherchen habe ich leider zwischen ca. 60, über 60.000 bis
>> hin zu 4 Milliarden alles gefunden.
> Wenn es eine Grenze gibt, ist die wohl durch das Betriebs- bzw.
> Dateisystem vorgegeben (max. Anzahl Dateien in einem Verzeichnis).
Das hatte ich auch schon vermutet. Gibt es hierzu vielleicht auch
irgendwo in der Doku einen Hinweis auf diese Hypothese oder schließt du
das einfach aus der Tatsache das MySQL auf Dateibasis arbeitet?
Ciao Markus
Niels Braczek
> Hi Niels,
>
>>> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
>> Offensichtlich liegt eine evtl. Begrenzung nicht innerhalb von MySQL,
>> denn sonst wäre das hier aufgeführt:
>> http://dev.mysql.com/doc/refman/5.1/en/limits.html
>
> Das hatte ich wohl in der deutschen Doku übersehen. Hätte vielleicht mal
> auf Englisch schauen sollen. Allerdings schießt es in meinem Fall u.U.
> das Limit auf 61 Tabellen innerhalb eines JOINS das ich MySQL nutzen kann.
Erst der Blick ins englische Manual ist wirklich ein Blick ins Manual ;-)
>> Wenn es eine Grenze gibt, ist die wohl durch das Betriebs- bzw.
>> Dateisystem vorgegeben (max. Anzahl Dateien in einem Verzeichnis).
>
> Das hatte ich auch schon vermutet. Gibt es hierzu vielleicht auch
> irgendwo in der Doku einen Hinweis auf diese Hypothese oder schließt du
> das einfach aus der Tatsache das MySQL auf Dateibasis arbeitet?
Ersteres weiß ich nicht, Letzteres: Ja.
Claus Reibenstein
> Markus Deckmann schrieb:
>
>> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
>
> [...]
> Wenn es eine Grenze gibt, ist die wohl durch das Betriebs- bzw.
> Dateisystem vorgegeben (max. Anzahl Dateien in einem Verzeichnis).
Oder durch die Engine. Bei InnoDB z.B. hat weder das Betriebs- noch das
Dateisystem ein Wörtchen mitzureden. Zumindest nicht, was die Anzahl angeht.
Gruß. Claus
Markus Deckmann
>>> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
>> [...]
>> Wenn es eine Grenze gibt, ist die wohl durch das Betriebs- bzw.
>> Dateisystem vorgegeben (max. Anzahl Dateien in einem Verzeichnis).
> Oder durch die Engine. Bei InnoDB z.B. hat weder das Betriebs- noch das
> Dateisystem ein Wörtchen mitzureden. Zumindest nicht, was die Anzahl angeht.
Und eine widersprüchliche Antwort zu den bisherigen. ;-)
Wo finde ich Informationen zu diesem Thema? Meine Recherchen haben mir
da bis jetzt noch nicht so eindeutige Aussagen geliefert. Würde mich
freuen wenn du mir deine Quelle nennen könntest.
Ciao Markus
Axel Schwenke
>
> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
Mehr als du brauchst. Bei einem sauberen relationalen Design
stellt sich die Frage nicht. Wenn du mehr als eine dreistellige
Anzahl Tabellen hast, ist deine Modellierung sehr fragw�rdig.
Praktisch gibt es Limits, insbesondere f�r die Anzahl gleich-
zeitig genutzter Tabellen; z.B. weil Filehandles knapp werden.
Oder der Speicher f�r den Table Cache. Auch die diversen Tabellen
in INFORMATION_SCHEMA werden arg langsam, wenn man *sehr* viele
Tabellen hat.
Dazu eine kleine Anekdote: eine SAP-Datenbank hat "nackisch" schon
ca. 40.000 Tabellen (allerdings sind die meisten davon leer).
Kein Problem mit MySQL. Es gab auch mal einen Wettbewerb gegen
PostgreSQL. Dabei ging es darum, 1 Million Tabllen anzulegen.
Geht auch (allerdings war PG wohl schneller).
XL
Niels Braczek
> Wenn du mehr als eine dreistellige
> Anzahl Tabellen hast, ist deine Modellierung sehr fragwürdig.
Das ist IMHO zu pauschal. Die Verhältnisse im Shared Hosting zwingen
einen schon mal, mehrere eigentlich unabhängige Projekte in der einzig
verfügbaren Datenbank zu speichern. So habe ich zB. einen Test-Webspace
für Akzeptanz-Tests, der derzeit gut zwei Dutzend unabhängige
Joomla-Installationen in einer Datenbank hält - etwa 1400 Tabellen.
Claus Reibenstein
> Hi Claus,
>
>>>> Wieviele Tabellen kann man in einer MySQL-Datenbank maximal anlegen?
>>>
>>> [...]
>>> Wenn es eine Grenze gibt, ist die wohl durch das Betriebs- bzw.
>>> Dateisystem vorgegeben (max. Anzahl Dateien in einem Verzeichnis).
>>
>> Oder durch die Engine. Bei InnoDB z.B. hat weder das Betriebs- noch das
>> Dateisystem ein Wörtchen mitzureden. Zumindest nicht, was die Anzahl angeht.
>
> Und eine widersprüchliche Antwort zu den bisherigen. ;-)
?
> Wo finde ich Informationen zu diesem Thema? Meine Recherchen haben mir
> da bis jetzt noch nicht so eindeutige Aussagen geliefert. Würde mich
> freuen wenn du mir deine Quelle nennen könntest.
Tja, wenn ich eine hätte ...
Du solltest übrigens die Leerzeilen beim Zitieren nicht immer alle
wegwerfen. Sie dienen der besseren Lesbarkeit.
Gruß. Claus
Axel Schwenke
> Axel Schwenke schrieb:
>
>> Wenn du mehr als eine dreistellige
>
> Das ist IMHO zu pauschal. Die Verh�ltnisse im Shared Hosting zwingen
~~~~~~~~~~~~~~
Oh. Ich hab das Problem mal unterstrichen :)
> einen schon mal, mehrere eigentlich unabh�ngige Projekte in der einzig
> verf�gbaren Datenbank zu speichern. So habe ich zB. einen Test-Webspace
> f�r Akzeptanz-Tests, der derzeit gut zwei Dutzend unabh�ngige
> Joomla-Installationen in einer Datenbank h�lt - etwa 1400 Tabellen.
Ja, gut. Aber du hast da mit Sicherheit keine Last drauf. Schon gar
nicht auf allen "gut ein Dutzend" Test-Sites gleichzeitig.
Und deswegen ist das auch kein Widerspruch zu meiner Aussage. Eine
Joomla-Installation *hat* eben nur eine kleine dreistellige Anzahl
an Tabellen.
XL
Niels Braczek
> Niels Braczek <nbra...@freenet.de> wrote:
>> Axel Schwenke schrieb:
>>
>>> Wenn du mehr als eine dreistellige
>>
>> Das ist IMHO zu pauschal. Die Verhältnisse im Shared Hosting zwingen
> ~~~~~~~~~~~~~~
> Oh. Ich hab das Problem mal unterstrichen :)
>
>> verfügbaren Datenbank zu speichern. So habe ich zB. einen Test-Webspace
>> für Akzeptanz-Tests, der derzeit gut zwei Dutzend unabhängige
>
> Ja, gut. Aber du hast da mit Sicherheit keine Last drauf. Schon gar
> nicht auf allen "gut ein Dutzend" Test-Sites gleichzeitig.
Das ist richtig. Alle diese Sites haben keinen Traffic, der sprübar wäre
- es sind ja nur Showcases, in denen der Kunde sich Änderungen an seiner
Site ansehen kann, bevor sie bei ihm eingebaut werden.
> Und deswegen ist das auch kein Widerspruch zu meiner Aussage. Eine
> Joomla-Installation *hat* eben nur eine kleine dreistellige Anzahl
> an Tabellen.
Naja, du sagtest, meine Modellierung sei fragwürdig, da ich 1400
Tabellen in einer Datenbank habe. Das ist aber nicht der Fall. QED.
Axel Schwenke
>> Joomla-Installation *hat* eben nur eine kleine dreistellige Anzahl
>> an Tabellen.
>
> Tabellen in einer Datenbank habe. Das ist aber nicht der Fall. QED.
Du hast doch gar nichts modelliert? Modelliert haben die Joomla
Leute. Und die sind mit relativ (naja) wenig Tabellen rausgekommen.
Du hast dich nur entschieden, eine Menge davon auf eine Maschine
zu legen. Daran ist im Kontext auch nichts auszusetzen.
XL
Niels Braczek
> Niels Braczek <nbra...@freenet.de> wrote:
>> Naja, du sagtest, meine Modellierung sei fragwürdig, da ich 1400
>> Tabellen in einer Datenbank habe. Das ist aber nicht der Fall. QED.
>
> Du hast doch gar nichts modelliert? Modelliert haben die Joomla
> Leute. Und die sind mit relativ (naja) wenig Tabellen rausgekommen.
>
> Du hast dich nur entschieden, eine Menge davon auf eine Maschine
> zu legen. Daran ist im Kontext auch nichts auszusetzen.
Darauf wollte ich hinaus ;-)
Andreas Scherbaum
>
> Dazu eine kleine Anekdote: eine SAP-Datenbank hat "nackisch" schon
> ca. 40.000 Tabellen (allerdings sind die meisten davon leer).
Ich wusste schon immer, warum ich SAP nicht mag ;-)
> Kein Problem mit MySQL. Es gab auch mal einen Wettbewerb gegen
> PostgreSQL. Dabei ging es darum, 1 Million Tabllen anzulegen.
> Geht auch (allerdings war PG wohl schneller).
Man sollte fair sein und sagen, dass irgendjemand das auf
MySQL probiert hat. Nachdem das entsprechende Blogposting
raus war, hat das auch jemand (ich glaube, Greg war das)
mit PG probiert und festgestellt, dass es schneller war.
Greg sein Posting ist zwischenzeitlich aber verloren gegangen.
Als Wettbewerb war das nicht geplant.
Bis dann
--
Andreas 'ads' Scherbaum
Failure is not an option. It comes bundled with your Microsoft product.
(Ferenc Mantfeld)
Markus Deckmann
> Mehr als du brauchst. Bei einem sauberen relationalen Design
> stellt sich die Frage nicht. Wenn du mehr als eine dreistellige
> Anzahl Tabellen hast, ist deine Modellierung sehr fragw�rdig.
Von welcher Normalform sprichst du denn das du so ausschlie�lich
beurteilen kannst das die Modellierung fragw�rdig ist und mir die
Datenbank mehr bietet als ich brauche? 3./4. gehe ich mal davon aus, oder?
> Praktisch gibt es Limits, insbesondere f�r die Anzahl gleich-
> zeitig genutzter Tabellen; z.B. weil Filehandles knapp werden.
Das habe ich auch gelesen, hier liegt die Grenze derzeit bei 61 Tabellen
die gleichzeitig in einem JOIN genutzt werden k�nnen. Das k�nnte u.U.
bei meinem Vorhaben auch noch ein Problem werden. Aber das habe ich noch
nicht genauer durchgedacht.
> Dazu eine kleine Anekdote: eine SAP-Datenbank hat "nackisch" schon
> ca. 40.000 Tabellen (allerdings sind die meisten davon leer).
> Kein Problem mit MySQL. Es gab auch mal einen Wettbewerb gegen
> PostgreSQL. Dabei ging es darum, 1 Million Tabllen anzulegen.
> Geht auch (allerdings war PG wohl schneller).
Findet man hier noch verf�gbare Quellen dieses Wettbewerbs? Ich habe
leider nur Links gefunden die nicht mehr gingen.
Ciao Markus
Axel Schwenke
> Hi Axel,
>
>> Mehr als du brauchst. Bei einem sauberen relationalen Design
>> stellt sich die Frage nicht. Wenn du mehr als eine dreistellige
>> Anzahl Tabellen hast, ist deine Modellierung sehr fragw�rdig.
>
> Von welcher Normalform sprichst du denn das du so ausschlie�lich
> beurteilen kannst das die Modellierung fragw�rdig ist und mir die
> Datenbank mehr bietet als ich brauche?
Zeig mir dein Modell und ich zeig dir wo du falsch liegst.
Die Glaskugel ist au�er Haus, zum Putzen.
> 3./4. gehe ich mal davon aus, oder?
Welche Normalform, ist daf�r erst mal egal. Auch wenn 3. und 4.
dazu neigen, mehr Tabellen zu brauchen. Aber ein relationales
Modell hat im wesentlichen 3 Dimensionen:
- Anzahl Tabellen
- Anzahl Spalten pro Tabelle
- Anzahl Zeilen pro Tabelle
nur die dritte Dimension ist f�r sehr gro�e Zahlen offen.
Insbesondere darf nur die dritte Dimension von den tats�chlichen
Daten abh�ngen. Dinge wie "pro Kunde eine Tabelle" oder "pro
Nutzer eine Spalte" sind also schon mal Bullshit.
>> Praktisch gibt es Limits, insbesondere f�r die Anzahl gleich-
>> zeitig genutzter Tabellen; z.B. weil Filehandles knapp werden.
>
> Das habe ich auch gelesen, hier liegt die Grenze derzeit bei 61 Tabellen
> die gleichzeitig in einem JOIN genutzt werden k�nnen.
Das hat nichts mit Filehandles zu tun. Eher mit internen Daten-
strukturen, u.a. im Optimizer. BTW, vor 5.0 hat der Optimizer noch
alle m�glichen Tabellenreihenfolgen untersucht, um die beste zu
finden. Bei N Tabellen sind das im worst case N! M�glichkeiten.
Erst der greedy Optimizer in 5.0 erlaubt eine deutlich zweistellige
Zahl von Tabellen in einem JOIN (zumindest wenn man irgendwann auch
mal ein Ergebnis sehen will).
Siehe: http://dev.mysql.com/doc/refman/5.0/en/mysql-nutshell.html
> Das k�nnte u.U.
> bei meinem Vorhaben auch noch ein Problem werden.
Mir f�llt nur eine einzige Anwendung ein, wo man derartig viele
Tabellen in einem JOIN brauchen k�nnte: ein Data Warehouse mit
extrem vielen Dimensionstabellen. Da stellt sich dann eher die
Frage, ob MySQL �berhaupt geeignet ist.
> Aber das habe ich noch nicht genauer durchgedacht.
Scheint mir auch so ;)
>> Es gab auch mal einen Wettbewerb gegen
>> PostgreSQL. Dabei ging es darum, 1 Million Tabllen anzulegen.
>> Geht auch (allerdings war PG wohl schneller).
>
> Findet man hier noch verf�gbare Quellen dieses Wettbewerbs? Ich habe
> leider nur Links gefunden die nicht mehr gingen.
Ja, anscheinend ist das nicht (mehr) im Web. Aber ich kenne einen
der Beteiligten pers�nlich :)
Wie Andreas schon anmerkte, war das urspr�nglich auch kein Wettbewerb.
Es stellte sich nur die Frage, wieviele Tabellen man in MySQL denn
tats�chlich anlegen k�nnte. Also hat das mal jemand probiert und dann
dar�ber gepostet (ich glaube, damals waren Blogs noch nicht sehr
verbreitet). Es wurden dabei �brigens auch Bugs gefunden. Z.B. hatte
InnoDB ein Leak im Zusammenhang mit Metadaten.
XL
Markus Deckmann
> Zeig mir dein Modell und ich zeig dir wo du falsch liegst.
> Die Glaskugel ist au�er Haus, zum Putzen.
Abbilden von Graphen innerhalb einer Datenbank. Informationen dazu
findest du unter:
http://de.wikipedia.org/wiki/Graphentheorie
Je nachdem in welchem Bereich du diese Graphen einsetzt k�nnen dadurch,
zumindest nach der Theorie die ich gerade versuche zu verifizieren,
durchaus auch eine sehr hohe Anzahl an Tabellen entstehen. Also nicht
unbedingt eine falsche Modellierung sondern u.U. einfach nur wesentlich
kleiner gesplittet als du es dir bisher vorstellst.
Aber ich hatte schon erwartet das auf so eine Frage die Leute mit S�tzen
wie deinen reagieren. ;-)
>> 3./4. gehe ich mal davon aus, oder?
> Welche Normalform, ist daf�r erst mal egal. Auch wenn 3. und 4.
> dazu neigen, mehr Tabellen zu brauchen. Aber ein relationales
> Modell hat im wesentlichen 3 Dimensionen:
> - Anzahl Tabellen
> - Anzahl Spalten pro Tabelle
> - Anzahl Zeilen pro Tabelle
> nur die dritte Dimension ist f�r sehr gro�e Zahlen offen.
> Insbesondere darf nur die dritte Dimension von den tats�chlichen
> Daten abh�ngen. Dinge wie "pro Kunde eine Tabelle" oder "pro
> Nutzer eine Spalte" sind also schon mal Bullshit.
Und in einer 6. Normalform? Und komm mir jetzt bitte nicht mit: "Es gibt
keine 6.". K�nnte das die Tatsache sein wieso ich dir widerspreche das
meine Modellierung einen Fehler hat? ;-)
> Mir f�llt nur eine einzige Anwendung ein, wo man derartig viele
> Tabellen in einem JOIN brauchen k�nnte: ein Data Warehouse mit
> extrem vielen Dimensionstabellen. Da stellt sich dann eher die
> Frage, ob MySQL �berhaupt geeignet ist.
Welches Datenbanksystem w�rdest du in so einem Fall einsetzen?
>> Aber das habe ich noch nicht genauer durchgedacht.
> Scheint mir auch so ;)
Nicht zu fr�h schie�en, siehe oben. ;-)
> Wie Andreas schon anmerkte, war das urspr�nglich auch kein Wettbewerb.
> Es stellte sich nur die Frage, wieviele Tabellen man in MySQL denn
> tats�chlich anlegen k�nnte. Also hat das mal jemand probiert und dann
> dar�ber gepostet (ich glaube, damals waren Blogs noch nicht sehr
> verbreitet). Es wurden dabei �brigens auch Bugs gefunden. Z.B. hatte
> InnoDB ein Leak im Zusammenhang mit Metadaten.
Was genau waren hier denn die Probleme.
Ciao Markus
Axel Schwenke
> Hi Axel,
>
>> Zeig mir dein Modell und ich zeig dir wo du falsch liegst.
>> Die Glaskugel ist au�er Haus, zum Putzen.
>
> Abbilden von Graphen innerhalb einer Datenbank. Informationen dazu
> findest du unter:
>
> http://de.wikipedia.org/wiki/Graphentheorie
�hem. http://www.htwm.de/mathe/neu/?q=diplommaster
und dann scrollst du mal runter bis 1995
Das ist angewandte Graphentheorie.
> Je nachdem in welchem Bereich du diese Graphen einsetzt k�nnen dadurch,
> zumindest nach der Theorie die ich gerade versuche zu verifizieren,
> durchaus auch eine sehr hohe Anzahl an Tabellen entstehen. Also nicht
> unbedingt eine falsche Modellierung sondern u.U. einfach nur wesentlich
> kleiner gesplittet als du es dir bisher vorstellst.
Also rein f�r die Struktur eines Graphen reicht genau eine Tabelle:
create table edges {
edge_id serial,
int unsigned start_vertex,
int unsigned end_vertex
}
F�r entartete F�lle (Knoten an denen keine Kanten beginnen oder enden)
w�rde man noch eine weitere Tabelle f�r die Knoten vorsehen wollen.
Und wenn man mehrere Graphen in einer Datenbank speichern will, w�rde
jeweils noch eine graph_id dazukommen. Wenn man nicht-optionale
Attribute f�r Knoten und Kanten hat (z.B. Namen) dann w�rde man die
mit in die Basistabellen tun.
Nun k�nnen Knoten und Kanten eines Graphen noch zus�tzliche Attribute
haben. In meinem Fall war das nur eine Intaktwahrscheinlichkeit. Aber
es gibt andere Problemstellungen, wo man wom�glich einige hundert oder
gar tausend zus�tzliche Attribute haben will. Nur legt man dann nicht
notwendigerweise f�r jedes Attribut eine eigene Tabelle an. Sondern
man sortiert die Attribute nach ihrem Typ (genauer: dem SQL-Typ, der
f�r die Speicherung des Attributwerts verwendet wird). Dann speichert
man alle Attribute vom gleichen Typ in einer Tabelle:
create table edge_attr_double {
edge_id longint unsigned,
attr_name char(20),
attr_value double
}
insert into edge_attr_double (edge_id, attr_name, attr_value)
values (42, "reliability", 0.995), (42, "capacity", 10);
Wenn Attribute immer in Gruppen auftreten, k�nnte man eigene Tabellen
vorsehen die jeweils eine Spalte pro Attribut haben:
create table edge_attrgroup_foo {
edge_id longint unsigned,
foo1 int,
foo2 double,
foo3 decimal(20),
...
}
Oder wenn Attribute Vektoren oder Matrizen sind, w�rde man die
zeilenweise in eine Tabelle verfrachten:
create table edge_attr_matrix_bar {
edge_id longint unsigned,
index1 int unsigned,
index2 int unsigned,
value double
}
etc. pp.
>> Welche Normalform, ist daf�r erst mal egal. Auch wenn 3. und 4.
>> dazu neigen, mehr Tabellen zu brauchen. Aber ein relationales
>> Modell hat im wesentlichen 3 Dimensionen:
>> - Anzahl Tabellen
>> - Anzahl Spalten pro Tabelle
>> - Anzahl Zeilen pro Tabelle
>> nur die dritte Dimension ist f�r sehr gro�e Zahlen offen.
>> Insbesondere darf nur die dritte Dimension von den tats�chlichen
>> Daten abh�ngen. Dinge wie "pro Kunde eine Tabelle" oder "pro
>> Nutzer eine Spalte" sind also schon mal Bullshit.
>
> Und in einer 6. Normalform? Und komm mir jetzt bitte nicht mit: "Es gibt
> keine 6.". K�nnte das die Tatsache sein wieso ich dir widerspreche das
> meine Modellierung einen Fehler hat? ;-)
Wenn du mit nicht-relationalen Modellierungen spielen willst, dann
ist es eher nicht verwunderlich wenn du bei Anforderungen rauskommst,
die nicht-relational sind.
Ansonsten bist du mal wieder reichlich unkonkret. Obiges ist g�ngige
Normalisierungspraxis f�r existierende Problemstellungen und
existierende RDBMSe
>> Mir f�llt nur eine einzige Anwendung ein, wo man derartig viele
>> Tabellen in einem JOIN brauchen k�nnte: ein Data Warehouse mit
>> extrem vielen Dimensionstabellen. Da stellt sich dann eher die
>> Frage, ob MySQL �berhaupt geeignet ist.
>
> Welches Datenbanksystem w�rdest du in so einem Fall einsetzen?
Eins f�r Data Warehousing. Teradata. Red Brick. Was wei� ich.
Ist nicht mein Fachgebiet.
>> Es wurden dabei �brigens auch Bugs gefunden. Z.B. hatte
>> InnoDB ein Leak im Zusammenhang mit Metadaten.
>
> Was genau waren hier denn die Probleme.
Ein Speicherleck halt. Jedes CREATE TABLE belegt einen Slot im Data
Dictionary (genauer gesagt: in der gecacheten Version desselben).
Der Slot wurde beim DROP TABLE aber nicht wieder frei gegeben.
Zumindest in der Art. Ist lange her und nat�rlich l�ngst gefixt.
Aber im Prinzip kannst du beliebig viele Tabellen haben. Jede Tabelle
braucht halt ein .FRM File im Datadir. Je nach Engine auch noch jeweils
ein .MYD/.MYI/.IBD File. Oder mindestens eine Page im globalen InnoDB
Tablespace. So lange dir der Plattenplatz nicht ausgeht, oder das
Filesystem bei Directory-Operationen zu langsam wird, kannst du das
Spielchen eine ganze Weile treiben.
Nicht da� das irgendeinen realen Nutzen h�tte :)
XL
Niels Braczek
> Hi Axel,
>
>> Zeig mir dein Modell und ich zeig dir wo du falsch liegst.
>
> Abbilden von Graphen innerhalb einer Datenbank. Informationen dazu
> findest du unter:
Das ist die Problemstellung - nicht das Modell.
Für die Abbildung von beliebigen Graphen reichen im Prinzip zwei
Tabellen: die Inzidenzliste und die Knoteninhalte.
> Und in einer 6. Normalform? Und komm mir jetzt bitte nicht mit: "Es gibt
> keine 6.". Könnte das die Tatsache sein wieso ich dir widerspreche das
> meine Modellierung einen Fehler hat? ;-)
Wie sähe die 6. Normalform denn aus? Meines Wissens ist die 5.
Normalform dadurch ausgezeichnet, dass sie sich nicht weiter in
Relationen aufspalten lässt, ohne dass Information verloren geht.
Markus Deckmann
Erst mal danke f�r deine ausf�hrliche Antwort und das du dir die Zeit
nimmst dich mit meiner Problemstellung zu befassen.
>> Je nachdem in welchem Bereich du diese Graphen einsetzt k�nnen dadurch,
>> zumindest nach der Theorie die ich gerade versuche zu verifizieren,
>> durchaus auch eine sehr hohe Anzahl an Tabellen entstehen. Also nicht
>> unbedingt eine falsche Modellierung sondern u.U. einfach nur wesentlich
>> kleiner gesplittet als du es dir bisher vorstellst.
>
> Also rein f�r die Struktur eines Graphen reicht genau eine Tabelle:
>
> create table edges {
> edge_id serial,
> int unsigned start_vertex,
> int unsigned end_vertex
> }
Das ist soweit richtig und k�nnte in meinem Anwendungsfall auch so
eingesetzt werden. Ich f�r meinen Fall m�chte gerne einen RDF-Graphen,
der wenn ich das richtig verstanden habe auch auf der Graphentheorie
aufbaut, in einer Datenbank abbilden. Hier ergeben sich bereits in
relativ einfachen Wissensgebieten sofort eine Unmenge an Knoten die bei
meiner Recherche bei einfacher Ablage der Triple in einer
Datenbanktabelle angeblich nicht mehr so wirklich behandelbar sind und
dar�ber hinaus die eigentliche F�higkeit von RDF einschr�nken. Daher bin
ich den Weg gegangen f�r jeden Knoten eine eigene Datenbanktabelle
anzulegen die dann die entsprechenden Attribute als Spalten beinhaltet.
In einem zweiten Schritt dachte ich mir �ber Mapping-Tabellen die
Zuordnung der tats�chlichen Instanzen dieser Knoten dann miteinander zu
verbinden und so vielleicht eine wesentlich gr��ere Anzahl an Knoten in
der Datenbank speichern zu k�nnen.
> Nun k�nnen Knoten und Kanten eines Graphen noch zus�tzliche Attribute
> haben. In meinem Fall war das nur eine Intaktwahrscheinlichkeit. Aber
> es gibt andere Problemstellungen, wo man wom�glich einige hundert oder
> gar tausend zus�tzliche Attribute haben will. Nur legt man dann nicht
> notwendigerweise f�r jedes Attribut eine eigene Tabelle an. Sondern
> man sortiert die Attribute nach ihrem Typ (genauer: dem SQL-Typ, der
> f�r die Speicherung des Attributwerts verwendet wird). Dann speichert
> man alle Attribute vom gleichen Typ in einer Tabelle:
>
> create table edge_attr_double {
> edge_id longint unsigned,
> attr_name char(20),
> attr_value double
> }
> insert into edge_attr_double (edge_id, attr_name, attr_value)
> values (42, "reliability", 0.995), (42, "capacity", 10);
Knoten in RDF bestehen soweit ich das verstanden habe immer aus den 3
Elementen Subjekt-Pr�dikat-Objekt, wobei das Subjekt und Objekt
innerhalb einer Ontologie als Begriff gesehen werden k�nnen. Jeder
Begriff kann dabei dann verschiedene Attribute besitzen was mich zu der
Idee der oben angesprochenen Tabelle pro Begriff gebracht hat mit den
Attributen als Spalte innerhalb der Tabelle. �ber verschiedene
Mapping-Tabellen wollte ich dann die relationalen Abh�ngigkeiten
zwischen den begriffen setzen und die Instanzen die innerhalb der
Tabellen gespeichert sind verbinden.
> Wenn Attribute immer in Gruppen auftreten, k�nnte man eigene Tabellen
> vorsehen die jeweils eine Spalte pro Attribut haben:
>
> create table edge_attrgroup_foo {
> edge_id longint unsigned,
> foo1 int,
> foo2 double,
> foo3 decimal(20),
> ...
> }
>
> Oder wenn Attribute Vektoren oder Matrizen sind, w�rde man die
> zeilenweise in eine Tabelle verfrachten:
>
> create table edge_attr_matrix_bar {
> edge_id longint unsigned,
> index1 int unsigned,
> index2 int unsigned,
> value double
> }
>
> etc. pp.
Und hier bin ich jetzt ausgestiegen das in meinem Kopf auf meinen
RDF-Anwendungsfall zu �bertragen.
>> Und in einer 6. Normalform? Und komm mir jetzt bitte nicht mit: "Es gibt
>> keine 6.". K�nnte das die Tatsache sein wieso ich dir widerspreche das
>> meine Modellierung einen Fehler hat? ;-)
> Wenn du mit nicht-relationalen Modellierungen spielen willst, dann
> ist es eher nicht verwunderlich wenn du bei Anforderungen rauskommst,
> die nicht-relational sind.
Die relationalen Abh�ngigkeiten wollte ich mir in der 6. Normalform �ber
die sich aus der Logik ergebenden Mappingtabellen erzeugen. Wieso du
hier von nicht-relationalen Modellen sprichst verstehe ich noch nicht ganz.
> Ansonsten bist du mal wieder reichlich unkonkret. Obiges ist g�ngige
> Normalisierungspraxis f�r existierende Problemstellungen und
> existierende RDBMSe
Wie gesagt, ich versuche nachzuvollziehen und evtl. zu testen wie man
sehr gro�e RDF-Graphen in einer Datenbank unterbringen kann. Da
angeblich die blanke Ablage der Subjekt-Pr�dikat-Objekt-Tripel in einer
Datenbanktabelle zu Milliarden von Eintr�gen in einer Tabelle f�hrt war
es nachvollziehbar das es hier zu Problemen kommen k�nnte schon alleine
aufgrund der hohen Anzahl an Datens�tzen innerhalb einer Tabelle.
Ich werd mir deinen Aufbau f�r die Abbildung von Graphen nochmal genauer
durch den Kopf gehen lassen und in meine �berlegungen einflie�en lassen.
Wie gesagt, vielen Dank f�r deine M�hen mir das hier zu erkl�ren. ;-)
Ciao Markus
Markus Deckmann
> Das ist die Problemstellung - nicht das Modell.
> Für die Abbildung von beliebigen Graphen reichen im Prinzip zwei
> Tabellen: die Inzidenzliste und die Knoteninhalte.
Hier hat mir die Antwort von Axel sehr weitergeholfen...jetzt muss ich
sie nur noch irgendwie auf meinen Anwendungsfall übertragen. Konkret
geht es hierbei um die Abbildung von RDF-Graphen in einer Datenbank.
Dabei entstehen schon bei relativ einfachen Zusammenhängen eine sehr
hohe Anzahl an Tripel die gespeichert werden müssten.
>> Und in einer 6. Normalform? Und komm mir jetzt bitte nicht mit: "Es gibt
>> keine 6.". Könnte das die Tatsache sein wieso ich dir widerspreche das
>> meine Modellierung einen Fehler hat? ;-)
> Wie sähe die 6. Normalform denn aus? Meines Wissens ist die 5.
> Normalform dadurch ausgezeichnet, dass sie sich nicht weiter in
> Relationen aufspalten lässt, ohne dass Information verloren geht.
Soweit hatte ich die 5. Normalform auch verstanden und bei einer
weiteren Zerlegung müssten natürlich um die Datenintegrität sicher zu
stellen weitere Tabellen hinzugefügt werden die dieses sicher stellen.
Diese ergeben sich in meinen Augen bei dem RDF-Anwendungsfall allerdings
aus der zugrundeliegenden Ontologie die abgebildet werden soll und damit
auf logischem Weg was dem relationalen Modell doch nicht widerspricht, oder?
Ciao Markus
Christian Kirsch
... und entfernte alle Hinweise auf Vorautoren :-(
> Hier ergeben sich bereits in
> relativ einfachen Wissensgebieten sofort eine Unmenge an Knoten die bei
> meiner Recherche bei einfacher Ablage der Triple in einer
> Datenbanktabelle angeblich nicht mehr so wirklich behandelbar sind und
> darï¿œber hinaus die eigentliche Fï¿œhigkeit von RDF einschrï¿œnken.
Vielleicht solltest Du mal einen Blick auf das werfen, was es fï¿œr
Ontologien etc. schon *gibt*, z.B. von http://www.ontopia.net/?
Markus Deckmann
>> Hier ergeben sich bereits in
>> relativ einfachen Wissensgebieten sofort eine Unmenge an Knoten die bei
>> meiner Recherche bei einfacher Ablage der Triple in einer
>> Datenbanktabelle angeblich nicht mehr so wirklich behandelbar sind und
>> darï¿œber hinaus die eigentliche Fï¿œhigkeit von RDF einschrï¿œnken.
>
> Vielleicht solltest Du mal einen Blick auf das werfen, was es fï¿œr
> Ontologien etc. schon *gibt*, z.B. von http://www.ontopia.net/?
Danke fï¿œr den Link, den werde ich mir mal genauer ansehen. Da mich
allerdings auch die Architektur in der Praxis dahinter interessiert
nï¿œtzen mir fertige Produkte oder SDKs die mir diesen Hauptteil abnehmen
eigentlich nicht viel.
Ciao Markus
Christian Kirsch
Das Zeug ist OpenSource. Du darfst es Dir also angucken, ï¿œndern usw usw.
Aber Du darfst natï¿œrlich auch gerne ein zweites Rad erfinden.
Claus Reibenstein
> ich den Weg gegangen f�r jeden Knoten eine eigene Datenbanktabelle
Da ist der Designfehler.
Gru�. Claus
Niels Braczek
> Hi Niels,
>
>> Das ist die Problemstellung - nicht das Modell.
>> Für die Abbildung von beliebigen Graphen reichen im Prinzip zwei
>> Tabellen: die Inzidenzliste und die Knoteninhalte.
>
> Hier hat mir die Antwort von Axel sehr weitergeholfen...jetzt muss ich
> sie nur noch irgendwie auf meinen Anwendungsfall übertragen. Konkret
> geht es hierbei um die Abbildung von RDF-Graphen in einer Datenbank.
> Dabei entstehen schon bei relativ einfachen Zusammenhängen eine sehr
> hohe Anzahl an Tripel die gespeichert werden müssten.
Wie Axel auch bereits sagte: Die Menge der Datensätze ist erstmal
unerheblich.Wenn es Performanzprobleme gibt, lohnt es sich u.U. über
*De*-Normalisierung nachzudenken.
>> Wie sähe die 6. Normalform denn aus? Meines Wissens ist die 5.
>> Normalform dadurch ausgezeichnet, dass sie sich nicht weiter in
>> Relationen aufspalten lässt, ohne dass Information verloren geht.
> Soweit hatte ich die 5. Normalform auch verstanden und bei einer
> weiteren Zerlegung müssten natürlich um die Datenintegrität sicher zu
> stellen weitere Tabellen hinzugefügt werden die dieses sicher stellen.
Damit hast du immer noch nicht gesagt, was ich mir under 6NF vorstellen
soll. Für mich sagt die 5NF bereits, dass es niemals Sinn macht, eine
weitere Normalisierung anzustreben, weil dadurch Information
*vernichtet* würde.
> Diese ergeben sich in meinen Augen bei dem RDF-Anwendungsfall allerdings
> aus der zugrundeliegenden Ontologie die abgebildet werden soll und damit
> auf logischem Weg was dem relationalen Modell doch nicht widerspricht, oder?
Ich habe mich mit der Problematik von Triplestores[1] noch nicht weiter
befasst. Ich sehe zunächst zwei Gründe, die dagegen sprechen, so etwas
in SQL machen zu wollen: Bestehende Patente[2] und Performanz.
[1] http://en.wikipedia.org/wiki/Triplestore
[2]
http://v3.espacenet.com/publicationDetails/biblio?CC=US&NR=2003145022&KC=&FT=E
Markus Deckmann
> Das Zeug ist OpenSource. Du darfst es Dir also angucken, ï¿œndern usw usw.
> Aber Du darfst natï¿œrlich auch gerne ein zweites Rad erfinden.
Es geht mir nicht ums erfinden sondern ums verstehen und dazu gehï¿œrt in
meinem Fall Praxis. Aber wie gesagt, ich werde mir auf jeden Fall das
ganze mal anschauen und wenn es Open Source ist, was ich auf den ersten
Blick ï¿œbersehen habe, dann besteht fï¿œr mich ja jede Mï¿œglichkeit da mal
rein zu schauen wie es im Hintergrund gelï¿œst wird.
Ciao Markus
Markus Deckmann
>> ich den Weg gegangen f�r jeden Knoten eine eigene Datenbanktabelle
>
> Da ist der Designfehler.
Da es in diesem Bereich noch keine "Standard-Modellierung" gibt nach der
solche RDF-Graphen in Datenbanken abgebildet werden, sondern hier
derzeit noch geforscht wird inwieweit die verschiedenen Modellierungen
Vor- und Nachteile haben kann man das in meinen Augen nicht unbedingt
als Designfehler sehen. Aus reiner Datenbankmodellierungssicht gebe ich
dir nat�rlich Recht, nur...wie w�rde dein Ansatz aussehen f�r die
Speicherung sehr gro�er RDF-Graphen?
Ciao Markus
Markus Deckmann
> Wie Axel auch bereits sagte: Die Menge der Datensätze ist erstmal
> unerheblich.Wenn es Performanzprobleme gibt, lohnt es sich u.U. über
> *De*-Normalisierung nachzudenken.
Bei einer Denormalisierung gehen allerdings auch einige Möglichkeiten
des variablen Einsatzes der gespeicherten Aussagen verloren. In einem
normalen Datenbankmodell mag das durchaus ein Schritt sein um
Performance-Steigerungen zu erreichen, im semantischen Bereich hängen da
aber IMHO noch wesentlich mehr Elemente als nur die dadurch entstehende
Datenredundanz mit dran.
>> Soweit hatte ich die 5. Normalform auch verstanden und bei einer
>> weiteren Zerlegung müssten natürlich um die Datenintegrität sicher zu
>> stellen weitere Tabellen hinzugefügt werden die dieses sicher stellen.
>
> Damit hast du immer noch nicht gesagt, was ich mir under 6NF vorstellen
> soll. Für mich sagt die 5NF bereits, dass es niemals Sinn macht, eine
> weitere Normalisierung anzustreben, weil dadurch Information
> *vernichtet* würde.
Wenn man es weiter eindimensional sieht dann stimmt das. Dann führt
jeder weitere Normalisierungsvorgang, der in meinen Augen bereits in der
5. Normalform zu Informationsverlust aufgrund der Eindeutigkeit führt,
in jedem Fall zu einem Informationsverlust. Im Kopf habe ich hier ein
mehrdimensionales relationales Modell das aufeinander aufbaut. Quasi
eine Basisschicht in der 5. Normalform in der ersten Dimension und eine
weitere Schicht, die 6. Normalform, als darauf aufbauende Dimension,
abhängig von der dafür verwendeten Ontologie.
>> Diese ergeben sich in meinen Augen bei dem RDF-Anwendungsfall allerdings
>> aus der zugrundeliegenden Ontologie die abgebildet werden soll und damit
>> auf logischem Weg was dem relationalen Modell doch nicht widerspricht, oder?
>
> Ich habe mich mit der Problematik von Triplestores[1] noch nicht weiter
> befasst. Ich sehe zunächst zwei Gründe, die dagegen sprechen, so etwas
> in SQL machen zu wollen: Bestehende Patente[2] und Performanz.
>
> [1] http://en.wikipedia.org/wiki/Triplestore
> [2]
> http://v3.espacenet.com/publicationDetails/biblio?CC=US&NR=2003145022&KC=&FT=E
Die zwei Links sind mir bekannt, wobei ich mir das Patent im zweiten
Fall noch nicht näher angesehen habe. Außerdem geht es mir wie gesagt um
das verstehen des ganzen, nicht um das Neu-Erfinden eines Triplestores.
Demnach können mir bestehende Patente eigentlich egal sein.
Ciao Markus
Axel Schwenke
/me wrote
>> Also rein f�r die Struktur eines Graphen reicht genau eine Tabelle:
>>
>> create table edges {
>> edge_id serial,
>> int unsigned start_vertex,
>> int unsigned end_vertex
>> }
>
> Das ist soweit richtig und k�nnte in meinem Anwendungsfall auch so
> eingesetzt werden. Ich f�r meinen Fall m�chte gerne einen RDF-Graphen,
> der wenn ich das richtig verstanden habe auch auf der Graphentheorie
> aufbaut, in einer Datenbank abbilden.
RDF ist erstmal eine Menge von "Subjekt ==Pr�dikat==> Objekt" Ketten.
Da Subjekte und Objekte aus der gleichen Menge kommen, kann man jede
solche Kette als Kante eines Graphen auffassen. Insofern erscheint
die Speicherung dieses Graphen als Inzidenzliste nat�rlich.
Ob es allerdings *sinnvoll* ist alle Tripel in eine Tabelle zu werfen,
h�ngt davon ab, welche Operationen man auf den Daten vorhat. Eine SQL-
Datenbank kann dir z.B. in Windeseile alle Tripel auflisten, die bei
$FOO beginnen. Oder alle, die bei $BAR enden. Wo eine Datenbank ins
Straucheln kommt (und MySQL ganz besonders) w�re die Frage nach Wegen
von $FOO zu $BAR, wom�glich noch mit Einschr�nkungen auf die Menge
der Pr�dikate, die einen Weg definieren.
Verkompliziert wird die Lage zus�tzlich, weil man Pr�dikate auch
wiederum als RDF-Tripel beschreiben will. Das bringt extra noch eine
Hierarchie rein. SQL-Datenbanken sind nicht besonders gut f�r die
Arbeit auf Hierarchien. Oracle hat zwar CONNECT BY, aber besonders
gut optimiert d�rfte das nicht sein.
Prinzipiell kann man Hierarchien auch mit dem Nested Set Modell auf
SQL abbilden. Mit vermutlich wieder anderen Problemen.
Die englische Wikipedia hat unter Triplestore ja auch ein paar Pointer
auf praktisch erprobte Triple->SQL Mappings.
Aber egal wie man sich entscheidet; das hier
> Daher bin
> ich den Weg gegangen f�r jeden Knoten eine eigene Datenbanktabelle
> anzulegen die dann die entsprechenden Attribute als Spalten beinhaltet.
ist auf jeden Fall *keine* relationale Modellierung mehr. Entities
werden niemals auf SQL-Tabellen abgebildet, sondern immer nur auf
eine oder mehrere Zeilen in solchen Tabellen.
> Wie gesagt, ich versuche nachzuvollziehen und evtl. zu testen wie man
> sehr gro�e RDF-Graphen in einer Datenbank unterbringen kann. Da
> angeblich die blanke Ablage der Subjekt-Pr�dikat-Objekt-Tripel in einer
> Datenbanktabelle zu Milliarden von Eintr�gen in einer Tabelle f�hrt war
> es nachvollziehbar das es hier zu Problemen kommen k�nnte schon alleine
> aufgrund der hohen Anzahl an Datens�tzen innerhalb einer Tabelle.
Tabellen mit Milliarden von Zeilen sind die Spezialit�t von Daten-
banken. Eine Einschr�nkung besteht allerdings darin, da� man vorher
wissen mu�, welche Art von Operationen schnell sein soll. Anhand
dieser Information setzt man dann n�mlich die passenden Indizes.
Eine Tabelle ohne Index ist einfach eine ungeordnete Liste; jede
Suche ist eine vollst�ndige Durchmusterung und deswegen langsam.
Manchmal (oft?) ist es auch so, da� ein vollst�ndig normalisiertes
Schema bestimmte Operationen einfach nicht schnell ausf�hren kann.
Dann kann man das Schema gezielt denormalisieren; z.B. indem man
redundante (vorverarbeitete) Daten mit reinlegt.
Bei deinem RDF-Problem kann ich dir nicht weiterhelfen. Ich halte
den Ansatz auch f�r �bergeneralisiert (und dadurch �berkompliziert)
als da� ich dadurch irgendeinen praktischen Nutzen erwarten w�rde.
Aber wom�glich liege ich damit ja falsch...
XL
Claus Reibenstein
> Hi Claus,
>
>>> ich den Weg gegangen f�r jeden Knoten eine eigene Datenbanktabelle
>>
>> Da ist der Designfehler.
>
> Da es in diesem Bereich noch keine "Standard-Modellierung" gibt nach der
> solche RDF-Graphen in Datenbanken abgebildet werden, sondern hier
> derzeit noch geforscht wird inwieweit die verschiedenen Modellierungen
> Vor- und Nachteile haben kann man das in meinen Augen nicht unbedingt
> als Designfehler sehen.
Ich denke schon, dass man das kann.
> Aus reiner Datenbankmodellierungssicht gebe ich
> dir nat�rlich Recht, nur...wie w�rde dein Ansatz aussehen f�r die
> Speicherung sehr gro�er RDF-Graphen?
Ganz einfach: Alle Knoten in _eine_ Tabelle packen, mit einer ID
versehen und einen Index auf diese ID legen. Erst dann kann die
Datenbank ihre Vorteile im Umgang mit sehr gro�en Datenmengen
ausspielen, denn genau daf�r sind sie konzipiert und entsprechend optimiert.
Sehr viele Tabellen zu erzeugen, ist jedoch eher kontraproduktiv. Darauf
sind Datenbanken eher selten optimiert.
Gru�. Claus
Harald Wenninger
> Markus Deckmann schrieb:
>> Aus reiner Datenbankmodellierungssicht gebe ich
>> dir natürlich Recht, nur...wie würde dein Ansatz aussehen für die
>> Speicherung sehr großer RDF-Graphen?
> Ganz einfach: Alle Knoten in _eine_ Tabelle packen, mit einer ID
> versehen und einen Index auf diese ID legen. Erst dann kann die
> Datenbank ihre Vorteile im Umgang mit sehr großen Datenmengen
> ausspielen, denn genau dafür sind sie konzipiert und entsprechend optimiert.
> Sehr viele Tabellen zu erzeugen, ist jedoch eher kontraproduktiv. Darauf
> sind Datenbanken eher selten optimiert.
Man sollte vielleicht noch anmerken, dass sich bei einem sinnvollen
Datenbankmodell idR sich die Tabellenstruktur (also Tabellen und ihre
Spalten) nicht mehr ändert, egal wie sich die Daten ändern.
Gruß,
Harald
Markus Deckmann
>> Da es in diesem Bereich noch keine "Standard-Modellierung" gibt nach der
>> solche RDF-Graphen in Datenbanken abgebildet werden, sondern hier
>> derzeit noch geforscht wird inwieweit die verschiedenen Modellierungen
>> Vor- und Nachteile haben kann man das in meinen Augen nicht unbedingt
>> als Designfehler sehen.
>
> Ich denke schon, dass man das kann.
Ok, dann sind einige f�hige Wissenschaftler wohl v�llig auf dem Holzweg
was ihre Art angeht dieses Problem zu l�sen, genau nach diesem Schema. ;-)
>> Aus reiner Datenbankmodellierungssicht gebe ich
>> dir nat�rlich Recht, nur...wie w�rde dein Ansatz aussehen f�r die
>> Speicherung sehr gro�er RDF-Graphen?
>
> Ganz einfach: Alle Knoten in _eine_ Tabelle packen, mit einer ID
> versehen und einen Index auf diese ID legen. Erst dann kann die
> Datenbank ihre Vorteile im Umgang mit sehr gro�en Datenmengen
> ausspielen, denn genau daf�r sind sie konzipiert und entsprechend optimiert.
Ok, und eine Datenbank kommt in einer Tabelle mit bsp. 100-500
Milliarden Zeilen so ohne weiteres zurecht? Komisch das ich bei diesen
Mengen ganz andere Informationen im Netz finde und das genau der Grund
ist wieso die Tripel eher nicht in *einer* Tabelle gespeichert werden.
Aber die die das schon ausprobiert haben und festgestellt haben das das
f�r RDF-Graphen nicht brauchbar ist haben nat�rlich alle unrecht. Wieso
arbeitest du dann nicht in diesem Bereich, scheinbar hast du ja die
L�sung f�r einige deren Probleme und die jenigen w�rden sich sicher
freuen und dich k�niglich entlohnen. ;-)
> Sehr viele Tabellen zu erzeugen, ist jedoch eher kontraproduktiv. Darauf
> sind Datenbanken eher selten optimiert.
Und was nicht ist das nicht sein darf oder wie? Auf die Speicherung von
Tripel ist derzeit noch keine Datenbank so richtig ausgelegt. Genau
darum geht es doch. Einen Weg zu finden diese riesige Menge an Daten
bspw. in einem RDBMS zu speichern und dabei z.B. herauszufinden an
welchem Punkt die DB optimiert werden m�sste bzw. wie eine Speicherung
auf den bisherigen Datenbanken aussehen k�nnte.
Ciao Markus
Markus Deckmann
> Man sollte vielleicht noch anmerken, dass sich bei einem sinnvollen
> Datenbankmodell idR sich die Tabellenstruktur (also Tabellen und ihre
> Spalten) nicht mehr ändert, egal wie sich die Daten ändern.
Aus klassischer Datenbankmodellierungssicht 100%ig richtig, auch in
meinen Augen. ;-)
Ciao Markus
Claus Reibenstein
> Hi Claus,
>
>>> Da es in diesem Bereich noch keine "Standard-Modellierung" gibt nach der
>>> solche RDF-Graphen in Datenbanken abgebildet werden, sondern hier
>>> derzeit noch geforscht wird inwieweit die verschiedenen Modellierungen
>>> Vor- und Nachteile haben kann man das in meinen Augen nicht unbedingt
>>> als Designfehler sehen.
>>
>> Ich denke schon, dass man das kann.
>
> Ok, dann sind einige f�hige Wissenschaftler wohl v�llig auf dem Holzweg
> was ihre Art angeht dieses Problem zu l�sen, genau nach diesem Schema. ;-)
Soso, f�hige Wissenschaftler. Welche denn, und was genau haben die
geschrieben? Deine polemische Aussage ist viel zu allgemein gehalten, um
sie bewerten zu k�nnen.
Au�erdem habe ich in den letzten Jahrzehnten immer wieder festgestellt,
dass Wissenschaftler eher Theoretiker sind und oft wenig Ahnung von
praktischer Anwendung haben. Gilt nat�rlich nicht f�r alle.
>>> Aus reiner Datenbankmodellierungssicht gebe ich
>>> dir nat�rlich Recht, nur...wie w�rde dein Ansatz aussehen f�r die
>>> Speicherung sehr gro�er RDF-Graphen?
>>
>> Ganz einfach: Alle Knoten in _eine_ Tabelle packen, mit einer ID
>> versehen und einen Index auf diese ID legen. Erst dann kann die
>> Datenbank ihre Vorteile im Umgang mit sehr gro�en Datenmengen
>> ausspielen, denn genau daf�r sind sie konzipiert und entsprechend optimiert.
>
> Ok, und eine Datenbank kommt in einer Tabelle mit bsp. 100-500
> Milliarden Zeilen so ohne weiteres zurecht?
Ich denke schon, dass eine Datenbank mit 100-500 Milliarden Datens�tzen
in einer Tabelle besser zurecht kommt als mit 100-500 Milliarden
einzelnen Tabellen.
> Komisch das ich bei diesen
> Mengen ganz andere Informationen im Netz finde und das genau der Grund
> ist wieso die Tripel eher nicht in *einer* Tabelle gespeichert werden.
Aber sicher werden die Tripel auch nicht einzeln in jeweils einer
eigenen Tabelle gespeichert.
> Aber die die das schon ausprobiert haben und festgestellt haben das das
> f�r RDF-Graphen nicht brauchbar ist haben nat�rlich alle unrecht. Wieso
> arbeitest du dann nicht in diesem Bereich, scheinbar hast du ja die
> L�sung f�r einige deren Probleme und die jenigen w�rden sich sicher
> freuen und dich k�niglich entlohnen. ;-)
Was soll diese Polemik?
>> Sehr viele Tabellen zu erzeugen, ist jedoch eher kontraproduktiv. Darauf
>> sind Datenbanken eher selten optimiert.
>
> Und was nicht ist das nicht sein darf oder wie?
Wie meinen?
> Auf die Speicherung von
> Tripel ist derzeit noch keine Datenbank so richtig ausgelegt.
Inwiefern?
> Genau
> darum geht es doch. Einen Weg zu finden diese riesige Menge an Daten
> bspw. in einem RDBMS zu speichern und dabei z.B. herauszufinden an
> welchem Punkt die DB optimiert werden m�sste bzw. wie eine Speicherung
> auf den bisherigen Datenbanken aussehen k�nnte.
Das ist dann aber eine ganz andere Fragestellung als die, die in dem
Ausgangsposting dieses Threads zu lesen ist.
Gru�. Claus
Harald Wenninger
Nicht aus "klassischer Sicht", das ist schlicht und einfach die
Modellierung, auf die sämtliche RDBMS ausgelegt sind. Alles andere
funktioniert damit nicht richtig. Ein RDBMS ist nicht dafür ausgelegt,
ständig Änderungen an Tabellen vorzunehmen. Wenn du dein Problem
nicht auf die "klassische Weise" modelliert kriegst, dann sind RDBMS
völlig ungeeignet für dein Problem.
Gruß,
Harald
Markus Deckmann
> Nicht aus "klassischer Sicht", das ist schlicht und einfach die
> Modellierung, auf die sämtliche RDBMS ausgelegt sind. Alles andere
> funktioniert damit nicht richtig. Ein RDBMS ist nicht dafür ausgelegt,
> ständig Änderungen an Tabellen vorzunehmen. Wenn du dein Problem
> nicht auf die "klassische Weise" modelliert kriegst, dann sind RDBMS
> völlig ungeeignet für dein Problem.
Was ja nicht bedeutet das zukünftige RDBMS nicht auch auf solche
Anwendungsfälle optimiert werden könnten. Schlussendlich liegt hinter
einem solchen System auch nur ein mathematisches Modell der ganzen Sache
das man anpassen kann wenn man weiß wo es notwendig ist.
Ciao Markus
Markus Deckmann
> Soso, f�hige Wissenschaftler. Welche denn, und was genau haben die
> geschrieben? Deine polemische Aussage ist viel zu allgemein gehalten, um
> sie bewerten zu k�nnen.
Pers�nlich kenne ich davon nat�rlich keinen, bin selbst ja keiner davon
sondern auch nur praktischer Anwender mit Interesse an den
dahinterliegenden Mechanismen. Und die Aussagen gehen halt in die
Richtung das noch keiner so richtig sagen kann welche Art der
Modellierung die beste ist und wie man am besten gro�e RDF-Graphen in
einer Datenbank speichert.
> Au�erdem habe ich in den letzten Jahrzehnten immer wieder festgestellt,
> dass Wissenschaftler eher Theoretiker sind und oft wenig Ahnung von
> praktischer Anwendung haben. Gilt nat�rlich nicht f�r alle.
Da gebe ich dir nat�rlich recht, da hinter einem RDBMS im Endeffekt auch
nur ein mathematisches Modell der gesamten Sache steckt ist eine gute
Portion Theorie allerdings IMHO nicht die schlechteste Voraussetzung.
>> Ok, und eine Datenbank kommt in einer Tabelle mit bsp. 100-500
>> Milliarden Zeilen so ohne weiteres zurecht?
>
> Ich denke schon, dass eine Datenbank mit 100-500 Milliarden Datens�tzen
> in einer Tabelle besser zurecht kommt als mit 100-500 Milliarden
> einzelnen Tabellen.
Was ja nicht so bleiben muss wenn man mal wei� wo die tats�chlichen
Probleme liegen innerhalb des mathematischen Modells der DB.
>> Komisch das ich bei diesen
>> Mengen ganz andere Informationen im Netz finde und das genau der Grund
>> ist wieso die Tripel eher nicht in *einer* Tabelle gespeichert werden.
>
> Aber sicher werden die Tripel auch nicht einzeln in jeweils einer
> eigenen Tabelle gespeichert.
Da hast du noch was falsch verstanden, die von mir angepeilte
Modellierung bildet lediglich die abstrakte Struktur der ganzen Sache
ab. Die konkreten Instanzen der Tripel werden dann sicherlich in der
Tabelle gespeichert.
>>> Sehr viele Tabellen zu erzeugen, ist jedoch eher kontraproduktiv. Darauf
>>> sind Datenbanken eher selten optimiert.
>> Und was nicht ist das nicht sein darf oder wie?
>
> Wie meinen?
Siehe oben...was nicht ist kann sich schneller �ndern als du denkst.
Bisherige Datenbanken sind auf die 3.-4. Normalform optimiert, keine
Frage. Das dies allerdings, gerade im Anwendungsfall des semantischen
Bereichs, so bleibt ist nicht gesagt.
>> Auf die Speicherung von
>> Tripel ist derzeit noch keine Datenbank so richtig ausgelegt.
>
> Inwiefern?
Das es bei der 3.Normalform im Endeffekt so aussieht das die Tabelle
grob gesagt min. 3 Spalten besitzt (Subjekt, Pr�dikat, Objekt) und dort
die konkreten Instanzen der Tripel als Datenzeile gespeichert werden.
Dies f�hrt aber zu Einschr�nkungen der Flexibilit�t die RDF bietet und
stellt daher nur begrenzt eine M�glichkeit dar solche Tripel zu
speichern. Weiterhin haben scheinbar, trotz Indizes, die bisherigen
Datenbanken Probleme Milliarden solcher Tripel in angemessener Zeit in
einer Tabelle zu verwalten. Auch die Setzung von Indizes ist nicht so
einfach wie hier vielfach angenommen, da aufgrund der Flexibilit�t von
RDF die Art der Abfrage nicht unbedingt so ausschlu�frei
vorherbestimmbar ist als das bei klassischen DB-Anwendungen der Fall ist.
>> Genau
>> darum geht es doch. Einen Weg zu finden diese riesige Menge an Daten
>> bspw. in einem RDBMS zu speichern und dabei z.B. herauszufinden an
>> welchem Punkt die DB optimiert werden m�sste bzw. wie eine Speicherung
>> auf den bisherigen Datenbanken aussehen k�nnte.
>
> Das ist dann aber eine ganz andere Fragestellung als die, die in dem
> Ausgangsposting dieses Threads zu lesen ist.
Ich habe das Thema das meine Modellierung falsch sein k�nnte auch nicht
angefangen. Zu dieser Fragestellung sind wir im Laufe des Threads
gerutscht und ich versuche meinen Standpunkt hier darzustellen wieso ich
denke das es durchaus eine M�glichkeit sein k�nnte. F�r mich und meine
geplanten praktischen Versuche war es wichtig zu wissen inwieweit
Einschr�nkungen vorliegen in der Anzahl der Tabellen in einer Datenbank.
Das die Diskussion in die Richtung "Falsche Modellierung" abgerutscht
ist war nicht meine Absicht, obwohl ich damit schon gerechnet hatte.
Aber daher versuche ich ja hier darzulegen wieso ich davon ausgehe das
es u.U. durchaus eine L�sung darstellen k�nnte. Und sei es nur konkret
herauszufinden in welchem Bereich die Probleme auftauchen und welcher
genauen Art sie sind.
Ciao Markus
Niels Braczek
> Hi Harald,
>
>> Wenn du dein Problem
>> nicht auf die "klassische Weise" modelliert kriegst, dann sind RDBMS
>> völlig ungeeignet für dein Problem.
>
> Was ja nicht bedeutet das zukünftige RDBMS nicht auch auf solche
> Anwendungsfälle optimiert werden könnten. Schlussendlich liegt hinter
> einem solchen System auch nur ein mathematisches Modell der ganzen Sache
> das man anpassen kann wenn man weiß wo es notwendig ist.
Doch, das bedeutet es. Das Konzept der relationalen Datenbank ist dafür
nicht geeignet. Für Anforderungen, die nicht sich nicht (vernünftig,
performant, ...) auf ein relationales DBMS abbilden lassen, gibt es
Alternativen wie CouchDB oder für deine Anwendung spezielle TripleStores.
Harald Wenninger
> Aber daher versuche ich ja hier darzulegen wieso ich davon ausgehe das
> es u.U. durchaus eine Lösung darstellen könnte. Und sei es nur konkret
> herauszufinden in welchem Bereich die Probleme auftauchen und welcher
> genauen Art sie sind.
Es stellt keine Lösung dar, weil ein RDBMS dafür vom Konzept her nicht
geeignet ist. Du solltest dich nach etwas anderem umsehen.
Gruß,
Harald
Markus Deckmann
>> Was ja nicht bedeutet das zukünftige RDBMS nicht auch auf solche
>> Anwendungsfälle optimiert werden könnten. Schlussendlich liegt hinter
>> einem solchen System auch nur ein mathematisches Modell der ganzen Sache
>> das man anpassen kann wenn man weiß wo es notwendig ist.
>
> Doch, das bedeutet es. Das Konzept der relationalen Datenbank ist dafür
> nicht geeignet. Für Anforderungen, die nicht sich nicht (vernünftig,
> performant, ...) auf ein relationales DBMS abbilden lassen, gibt es
> Alternativen wie CouchDB oder für deine Anwendung spezielle TripleStores.
Da hast du dir jetzt wohl ins eigene Bein geschossen. ;-)
Link: http://couchdb.apache.org/
<Zitat>
Apache CouchDB is a document-oriented database that can be queried and
indexed in a MapReduce fashion using JavaScript.
</Zitat>
Dem entnehme ich das es sich hierbei um eine "document-oriented
database" handelt. Einmal kurz diesen Begriff in Google eingegeben
ergibt das folgende auf Wikipedia woraus ich auch zitieren will:
http://en.wikipedia.org/wiki/Document-oriented_database
<Zitat>
These systems may be implemented as a layer above a relational database
or an object database.
</Zitat>
Was in meinen Augen soviel bedeutet das CouchDB lediglich eine weitere
Schicht auf eine relationale bzw. objektorientierte Datenbank legt um
die Anforderungen zu erfüllen. Da damit das zugrundeliegende Modell
weiterhin das relationale wirst du mir sicherlich erklären wollen wieso
das relationale Modell deiner Meinung nach für sowas nicht geeignet sein
sollte? Schließlich basieren deine genannten Alternativen genau auf
diesem relationalen Modell und erweitern es lediglich um eine weitere
Schicht für die Dokument-Orientiertheit. ;-)
Auch bei den TripleStores verhält es sich nicht recht viel anders und
auch hier hast du dir teilweise mit deiner Antwort ins eigene Bein
geschossen:
http://en.wikipedia.org/wiki/Triplestore
<Zitat>
Some triplestores have been built as database engines from scratch,
while others have been built on top of existing commercial relational
database engines (i.e. SQL-based).
</Zitat>
Teilweise daher weil es, wie du richtig behauptest, Datenbanken gibt die
schon von vornherein auf diese Art der Speicherung aufgebaut sind,
dennoch "others have been built on top of existing commercial relational
database engines", was soviel bedeutet das es auch Lösungen gibt die auf
dem relationalen Modell basieren.
Sowohl CouchDB als auch ein TripleStore muss nicht zwangsläufig ein
NICHT-relationales Modell besitzen. Also was genau wolltest du mir doch
gleich mit deiner Antwort mitteilen? ;-)
Ciao Markus
Markus Deckmann
>> Aber daher versuche ich ja hier darzulegen wieso ich davon ausgehe das
>> es u.U. durchaus eine Lösung darstellen könnte. Und sei es nur konkret
>> herauszufinden in welchem Bereich die Probleme auftauchen und welcher
>> genauen Art sie sind.
>
> Es stellt keine Lösung dar, weil ein RDBMS dafür vom Konzept her nicht
> geeignet ist. Du solltest dich nach etwas anderem umsehen.
Siehe Antwort auf Nils Braczeks Posting um 13:13 und meine Antwort um 16:07.
Sowohl die Alternativen als auch TripleStores basieren vielfach auf dem
relationalen Modell, wieso dieses dafür nicht geeignet sein soll
entzieht sich daher meinem Verständniss. ;-)
Ciao Markus
Harald Wenninger
>>> Aber daher versuche ich ja hier darzulegen wieso ich davon ausgehe das
>>> es u.U. durchaus eine Lösung darstellen könnte. Und sei es nur konkret
>>> herauszufinden in welchem Bereich die Probleme auftauchen und welcher
>>> genauen Art sie sind.
>> Es stellt keine Lösung dar, weil ein RDBMS dafür vom Konzept her nicht
>> geeignet ist. Du solltest dich nach etwas anderem umsehen.
> Sowohl die Alternativen als auch TripleStores basieren vielfach auf dem
> relationalen Modell, wieso dieses dafür nicht geeignet sein soll
> entzieht sich daher meinem Verständniss. ;-)
Dann hast du bis jetzt noch nicht die richtige Modellierung
gefunden. Deine Idee mit den vielen Tabellen ist sicher falsch.
Vielleicht schaust du dir mal die Datenbankmodellierung in den von dir
oben genannten Produkten an.
Gruß,
Harald
Markus Deckmann
> Dann hast du bis jetzt noch nicht die richtige Modellierung
> gefunden. Deine Idee mit den vielen Tabellen ist sicher falsch.
> Vielleicht schaust du dir mal die Datenbankmodellierung in den von dir
> oben genannten Produkten an.
Wenn ich das richtig auf die schnelle Überblicke arbeiten die meisten
TripleStores nach dem Prinzip das sie die Verwaltungsebene (ein anderer
Begriff fällt mir jetzt grad nicht ein) in der Datenbank vorhalten, die
eigentlichen Daten dann aber als XML o.ä. Format außerhalb der Datenbank
ablegen. Das ist aber ein gänzlich anderer Ansatz wie den den ich
verfolge da bei mir sowohl die abstrakte Struktur als auch die konkreten
Instanzen in der Datenbank abgebildet werden sollen.
Bei den TripleStores bzw. Layern die auf dem relationalen Modell
aufsetzen habe ich nach anfänglichen Recherchen allerdings wie gesagt
eher das Gefühl das lediglich, wenn überhaupt, die abstrakte Struktur in
der Datenbank vorgehalten wird, die konkreten Instanzen dann allerdings
als Datei auf der Festplatte liegen und gesondert verarbeitet werden
müssen. In diesem Fall kann ich allerdings dann auch gleich auf die
RDF-Dateien, die ebenfalls auf XML basieren, zurückgreifen und diese
direkt verarbeiten. Das ist allerdings dann keine Speicherung in einer
Datenbank wie ich finde.
Ciao Markus
Niels Braczek
> Hi Niels,
>
>> nicht geeignet. Für Anforderungen, die nicht sich nicht (vernünftig,
>> performant, ...) auf ein relationales DBMS abbilden lassen, gibt es
>> Alternativen wie CouchDB oder für deine Anwendung spezielle TripleStores.
>
> Da hast du dir jetzt wohl ins eigene Bein geschossen. ;-)
>
> Link: http://couchdb.apache.org/
> <Zitat>
> Apache CouchDB is a document-oriented database that can be queried and
> indexed in a MapReduce fashion using JavaScript.
> </Zitat>
>
> Dem entnehme ich das es sich hierbei um eine "document-oriented
> database" handelt. Einmal kurz diesen Begriff in Google eingegeben
> ergibt das folgende auf Wikipedia woraus ich auch zitieren will:
>
> http://en.wikipedia.org/wiki/Document-oriented_database
> <Zitat>
> These systems may be implemented as a layer above a relational database
> or an object database.
> </Zitat>
>
> Was in meinen Augen soviel bedeutet das CouchDB lediglich eine weitere
> Schicht auf eine relationale bzw. objektorientierte Datenbank legt um
> die Anforderungen zu erfüllen.
Nein. "may" heißt in keiner Weise "is". Das Konzept von CouchDB ist
Dokument-orientiert und nicht Relation-orientiert. Dass man das eine auf
das andere abbilden *kann* (und manche es auch tun) bedeutet nicht, dass
die Konzepte letztlich gleich sind (vgl. hierzu prozedurale vs.
objektorientierte Programmierung; in beiden lässt sich praktisch alles
programmieren, dennoch sind die Ansätze völlig verschieden).
> Da damit das zugrundeliegende Modell
> weiterhin das relationale
Hier irrst du dich.
> wirst du mir sicherlich erklären wollen wieso
> das relationale Modell deiner Meinung nach für sowas nicht geeignet sein
> sollte? Schließlich basieren deine genannten Alternativen genau auf
> diesem relationalen Modell und erweitern es lediglich um eine weitere
> Schicht für die Dokument-Orientiertheit. ;-)
Nein, das ist deine Fehlinterpretation.
> Auch bei den TripleStores verhält es sich nicht recht viel anders und
> auch hier hast du dir teilweise mit deiner Antwort ins eigene Bein
> geschossen:
>
> http://en.wikipedia.org/wiki/Triplestore
> <Zitat>
> Some triplestores have been built as database engines from scratch,
> while others have been built on top of existing commercial relational
> database engines (i.e. SQL-based).
> </Zitat>
Hier dasselbe: Die Tatsache, dass einige ("some") das so machen, heißt
noch lange nicht, dass letztlich ein relationaler Ansatz dahinter steckt.
> Sowohl CouchDB als auch ein TripleStore muss nicht zwangsläufig ein
> NICHT-relationales Modell besitzen. Also was genau wolltest du mir doch
> gleich mit deiner Antwort mitteilen? ;-)
Ich denke, das weißt du recht genau.
Niels Braczek
> Hi Niels,
>
>>> Was ja nicht bedeutet das zukünftige RDBMS nicht auch auf solche
>>> Anwendungsfälle optimiert werden könnten. Schlussendlich liegt hinter
>>> einem solchen System auch nur ein mathematisches Modell der ganzen Sache
>>> das man anpassen kann wenn man weiß wo es notwendig ist.
>>
>> Doch, das bedeutet es. Das Konzept der relationalen Datenbank ist dafür
>> nicht geeignet. Für Anforderungen, die nicht sich nicht (vernünftig,
>> performant, ...) auf ein relationales DBMS abbilden lassen, gibt es
>> Alternativen wie CouchDB oder für deine Anwendung spezielle TripleStores.
>
> Da hast du dir jetzt wohl ins eigene Bein geschossen. ;-)
Ok, etwas allgemeiner:
Es gibt im Wesentlichen vier Datenbankmodelle[1]:
* hierarchisch: Die Datenobjekte können ausschließlich in einer
Eltern-Kind-Beziehung zueinander stehen.
* netzwerkartig: Die Datenobjekte werden miteinander in Netzen
verbunden.
* relational: Die Daten werden zeilenweise in Tabellen verwaltet. Es
kann beliebige Beziehungen zwischen Daten geben. Sie werden durch
Werte bestimmter Tabellenspalten festgelegt.
* objektorientiert: Die Beziehungen zwischen Datenobjekten werden vom
Datenbanksystem selbst verwaltet. Objekte können Eigenschaften und
Daten von anderen Objekten erben.
Aufgrund der Mächtigkeit des relationalen Modells ("beliebige
Beziehungen zwischen Daten") können die anderen meist auf dieses Modell
abgebildet werden. Die speziellen Stärken der anderen Modelle bleiben
dabei allerdings meist auf der Strecke.
Für RDF benötigt man ganz klar das netzwerkartige Modell.
[1] Quelle: Wikipedia
Niels Braczek
> In diesem Fall kann ich allerdings dann auch gleich auf die
> RDF-Dateien, die ebenfalls auf XML basieren, zurückgreifen und diese
> direkt verarbeiten. Das ist allerdings dann keine Speicherung in einer
> Datenbank wie ich finde.
Du verwechselst "Datenbank"[1] mit "Datenbankmanagementsystem"[2] und
meinst zudem speziell "relationales Datenbankmanagementsystem"[3]. Bei
einer fachlichen Diskussion, die wie diese einen recht hohen
Kenntnisstand verlangt, ist eine saubere Terminologie unabdingbar.
[1] Menge der zu verwaltenden Daten
[2] organisiert intern die strukturierte Speicherung der Daten und
kontrolliert alle lesenden und schreibenden Zugriffe auf die
Datenbank
[3] Alle Operationen basieren theoretisch auf der relationalen Algebra.
Die Relationale Algebra bietet keine Unterstützung zur Berechnung
von rekursiven Anfragen (Transitive Hülle).
Markus Deckmann
>> Was in meinen Augen soviel bedeutet das CouchDB lediglich eine weitere
>> Schicht auf eine relationale bzw. objektorientierte Datenbank legt um
>> die Anforderungen zu erfüllen.
>
> Nein. "may" heißt in keiner Weise "is". Das Konzept von CouchDB ist
> Dokument-orientiert und nicht Relation-orientiert. Dass man das eine auf
> das andere abbilden *kann* (und manche es auch tun) bedeutet nicht, dass
> die Konzepte letztlich gleich sind (vgl. hierzu prozedurale vs.
> objektorientierte Programmierung; in beiden lässt sich praktisch alles
> programmieren, dennoch sind die Ansätze völlig verschieden).
Es ging nicht um eine Abbildung sondern um eine Abstraktionsschicht...
>> wirst du mir sicherlich erklären wollen wieso
>> das relationale Modell deiner Meinung nach für sowas nicht geeignet sein
>> sollte? Schließlich basieren deine genannten Alternativen genau auf
>> diesem relationalen Modell und erweitern es lediglich um eine weitere
>> Schicht für die Dokument-Orientiertheit. ;-)
>
> Nein, das ist deine Fehlinterpretation.
Dann musst du mir erklären was du an dem Wort "Layer", was man
gleichsetzen kann mit "Abstraktionsschicht", falsch verstehst um mir
hier eine Fehlinterpretation zu unterstellen. ;-)
>> Auch bei den TripleStores verhält es sich nicht recht viel anders und
>> auch hier hast du dir teilweise mit deiner Antwort ins eigene Bein
>> geschossen:
>>
>> http://en.wikipedia.org/wiki/Triplestore
>> <Zitat>
>> Some triplestores have been built as database engines from scratch,
>> while others have been built on top of existing commercial relational
>> database engines (i.e. SQL-based).
>> </Zitat>
>
> Hier dasselbe: Die Tatsache, dass einige ("some") das so machen, heißt
> noch lange nicht, dass letztlich ein relationaler Ansatz dahinter steckt.
Na und hier irrst du dich. In den Fällen in denen das ganze "built on
top" ist, handelt es sich sehr wohl grundsätzlich um relationale
Modelle, auch wenn dir sich dieser Zusammenhang offensichtlich nicht
erschließt.
>> Sowohl CouchDB als auch ein TripleStore muss nicht zwangsläufig ein
>> NICHT-relationales Modell besitzen. Also was genau wolltest du mir doch
>> gleich mit deiner Antwort mitteilen? ;-)
>
> Ich denke, das weißt du recht genau.
Nein, das einzige was ich derzeit mit Sicherheit weiß ist die Tatsache
das du hier versuchst eindeutige Aussagen so zurecht zu biegen das sie
auf deine Argumentation passen. Aber einen Fehler eingestehen fällt nie
leicht, gell? ;-)
Ciao Markus
Markus Deckmann
> Es gibt im Wesentlichen vier Datenbankmodelle[1]:
>
> * hierarchisch: Die Datenobjekte können ausschließlich in einer
> Eltern-Kind-Beziehung zueinander stehen.
Ok, soweit richtig, weiterhin steht auf Wikipedia [1] allerdings auch:
<Zitat>
Der Nachteil von hierarchischen Datenbanken ist, dass sie nur mit einem
solchen Baum umgehen können. Verknüpfungen zwischen verschiedenen Bäumen
oder über mehrere Ebenen innerhalb eines Baumes sind nicht möglich.
</Zitat>
Da du selbst weiter unten angibst das das relationale Modell beliebige
Beziehungen zwischen den Daten abbilden kann ist in diesem Fall das
hierarchische Datenbankmodell weniger mächtig als das relationale. Dort
könnte ich nämlich rein theorethisch auch Verknüpfungen zwischen
verschiedenen Bäumen herstellen und auch zwischen Ebenen eines Baumes.
> * netzwerkartig: Die Datenobjekte werden miteinander in Netzen
> verbunden.
Hier zitiere ich eine andere Seite [2] auf der steht:
<Zitat>
Netzwerkartige Datenbank: vom prinzipiellen Aufbau her um ein ähnlich
wie die hierarchische DB, aber: er können auch noch einzelne
Verbindungen zwischen den Datensätzen bestehen => etwas flexibler, da
zur Erlangung einer Information nicht mehr ganze Hierarchie durchlaufen
werden muß
</Zitat>
Auch das bedeutet das hier die die Hierarchie teilweise schon vorgegeben
ist und damit der Suchaufwand erheblich reduziert werden kann. Das
allerdings stellt auch eine Einschränkung vom relationalen Modell deiner
eigenen Definition ("beliebige Beziehungen zwischen Daten") dar und
schränkt damit die Mächtigkeit des relationalen Modells ebenfalls ein.
> * relational: Die Daten werden zeilenweise in Tabellen verwaltet. Es
> kann beliebige Beziehungen zwischen Daten geben. Sie werden durch
> Werte bestimmter Tabellenspalten festgelegt.
Hier wären wir dann beim mächtigsten Modell [3] das, wie du selbst an
anderer Stelle angibst, beliebige Beziehungen zwischen den Daten erlaubt
und bei der OPERATIONEN auf diesem Modell der "Relationalen Algebra" [4]
folgen. Das hat mal erst noch gar nichts mit dem Modell in dem die Daten
gespeichert sind zu tun sondern eher mit dem Zugriff und der Änderung
dieser Daten. Das solltest du trennen in deinem Kopf.
> * objektorientiert: Die Beziehungen zwischen Datenobjekten werden vom
> Datenbanksystem selbst verwaltet. Objekte können Eigenschaften und
> Daten von anderen Objekten erben.
Auch diese Form der Datenmodell-Abbildung schließt lediglich einige
Lücken die sich, wie du selbst zugibst, auch auf dem relationalen Modell
abbilden lassen. Anders als bei der objektorientierten [5]
Rangehensweise kann man hier einige Erleichterungen bei der Arbeit mit
den Daten erreichen die beim relationalen Modell nicht gegeben sind.
> Aufgrund der Mächtigkeit des relationalen Modells ("beliebige
> Beziehungen zwischen Daten") können die anderen meist auf dieses Modell
> abgebildet werden. Die speziellen Stärken der anderen Modelle bleiben
> dabei allerdings meist auf der Strecke.
Die Stärken entstehen aber nicht aus einem völlig neuen Paradigma der
Speicherung so wie du es hier postulieren willst sondern aus einer
gezielten Einschränkung oder Vor-Strukturierung der Speicherung und
stellen damit eher einen AUFsatz als einen ERsatz für das relationale
Modell dar.
> Für RDF benötigt man ganz klar das netzwerkartige Modell.
Da widerspreche ich dir nicht im geringsten. Was nicht, wie von dir
behauptet, automatisch dazu führt das die Hauptmenge, das relationale
Modell, schlechter für das Vorhaben ist als eine Teilmenge, die anderen
Modelle. ;-)
Ciao Markus
[1] http://de.wikipedia.org/wiki/Hierarchisches_Datenbankmodell
[2] http://cartoon.iguw.tuwien.ac.at/fit/fit07/konzept_datenbanken.html
[3] http://de.wikipedia.org/wiki/Relationale_Datenbank
[4] http://de.wikipedia.org/wiki/Relationale_Algebra
[5] http://de.wikipedia.org/wiki/Objektdatenbank
Markus Deckmann
> Du verwechselst "Datenbank"[1] mit "Datenbankmanagementsystem"[2] und
> meinst zudem speziell "relationales Datenbankmanagementsystem"[3]. Bei
Haben wir dann vielleicht bei DIR und nicht bei mir des Pudels Kern
gefunden? Ich spreche nämlich schon die ganze Zeit von dem
dahinterliegenden mathemathischen Modell, sprich dem relationalen Modell.
> einer fachlichen Diskussion, die wie diese einen recht hohen
> Kenntnisstand verlangt, ist eine saubere Terminologie unabdingbar.
Auch hier bin ich voll deiner Meinung.
> [1] Menge der zu verwaltenden Daten
> [2] organisiert intern die strukturierte Speicherung der Daten und
> kontrolliert alle lesenden und schreibenden Zugriffe auf die
> Datenbank
> [3] Alle Operationen basieren theoretisch auf der relationalen Algebra.
> Die Relationale Algebra bietet keine Unterstützung zur Berechnung
> von rekursiven Anfragen (Transitive Hülle).
Dann bleibe doch auch mal bitte auf der Basis von deinem definierten [1]
und bringe nicht selbst noch [2] und [3] mit rein. Die haben hier
nämlich erst mal noch gar nichts verloren da wir uns bis jetzt rein über
das folgende bis jetzt unterhalten. Wenn das nicht so ist liegst du
falsch, nicht ich.
http://de.wikipedia.org/wiki/Semantisches_Datenmodell
Und ein derartiges Datenmodell hat erst mal noch nichts mit dem System
zu tun das diese Struktur dann abbildet und auch nicht mit der
relationalen Algebra die für einen Zugriff auf diese Daten notwendig
ist, sondern lediglich mit der abstrakten Form der Struktur die dann in
den verschiedensten Formen und Farben abgebildet werden kann. ;-)
Kann es sein das du mir in meine Sätze mehr reininterpretierst nur um
deine Argumentation zu stützen als ich tatsächlich gesagt habe?
Ciao Markus
Claus Reibenstein
> Hi Harald,
>
>> Nicht aus "klassischer Sicht", das ist schlicht und einfach die
>> Modellierung, auf die sämtliche RDBMS ausgelegt sind. Alles andere
>> funktioniert damit nicht richtig. Ein RDBMS ist nicht dafür ausgelegt,
>> ständig Änderungen an Tabellen vorzunehmen. Wenn du dein Problem
>> nicht auf die "klassische Weise" modelliert kriegst, dann sind RDBMS
>> völlig ungeeignet für dein Problem.
>
> Was ja nicht bedeutet das zukünftige RDBMS nicht auch auf solche
> Anwendungsfälle optimiert werden könnten.
Wenn Du das 'R' weglässt, könnte ein Schuh daraus werden. Aber mit dem
'R' bedeutet es genau das.
> Schlussendlich liegt hinter
> einem solchen System auch nur ein mathematisches Modell der ganzen Sache
Und zwar genau eins.
Gruß. Claus
Claus Reibenstein
> Hi Niels,
>
>>> wirst du mir sicherlich erklären wollen wieso
>>> das relationale Modell deiner Meinung nach für sowas nicht geeignet sein
>>> sollte? Schließlich basieren deine genannten Alternativen genau auf
>>> diesem relationalen Modell und erweitern es lediglich um eine weitere
>>> Schicht für die Dokument-Orientiertheit. ;-)
>>
>> Nein, das ist deine Fehlinterpretation.
>
> Dann musst du mir erklären was du an dem Wort "Layer", was man
> gleichsetzen kann mit "Abstraktionsschicht", falsch verstehst um mir
> hier eine Fehlinterpretation zu unterstellen. ;-)
Du hast "may" offensichtlich immer noch nicht verstanden.
Hier noch einmal der entscheidende Satz:
These systems _may_ be implemented as a layer above a relational
database or an object database.
Auf deutsch: Diese Systeme _können_ als ein Layer über einer
relationalen Datenbank oder einer Objektdatenbank realisiert werden.
Das heißt aber eben _nicht_, dass sie auch so realisiert werden
_müssen_. Insbesondere bedeutet das, dass diese Alternativen eben
_nicht_ auf diesem relationalen Modell basieren. Sie benutzen ein
_eigenes_ Modell (eben das dokumentenorientierte).
Jetzt klar?
Gruß. Claus