nicht angemeldet
komplexe Objekte effizient in rel. DB speichern
Hallo Forum!
Ich möchte eine große Menge Objekte in einer Datenbank speichern. Ansich eine normale Sache - allerdings ist die Beschreibung wie solch ein Objekt aussieht selbst auch in der DB gespeichert, d.h. es können vom Benutzer neue Objektklassen erzeugt werden (z.B. "Buch" besteht aus Seitenzahl (int), Herausgabejahr (date), Zusammenfassung (text), Autor (string), verfügbar (bool)).
Wie kann ich diese Objekte nun effizient speichern, wenn ich vorher nichts über die Struktur weiß? Einfach CREATE TABLE statements zu generieren halte ich für wenig "elegant"...
Meine Idee wäre pro Datentyp eine Tabelle zu machen (data_bool, data_int, data_string ...) die den jeweiligen Wert und die Objekt-ID enthalten, dann müsste ich bei jeder Abfrage alle diese Tabellen nach Inhalten für das gesuchte Objekt befragen.
Hat jemand sowas schonmal besser gelöst ?
Grüße,
Peter
-
Hi,
wenn deine DB außer relationalen Tabellen auch noch XML (nativ) beherrscht, würde ich dir empfehlen XML mit XSD (Schemas) zusammen zu verwenden.
Relationale Tabellen für XML als Binärdaten zu missbrauchen halte ich für suboptimal, da man die Daten nicht an einem Stück abfragen oder validieren kann.
Es gibt auf dem Markt (damit schließe ich OpenSource nicht aus) Tools/Frameworks zur Objektpersistierung, die Firma "Versant" kommt mir da direkt in den Sinn, ohne dass ich die Qualität deren Lösung kommentieren möchte.
Ansonsten ist der Ansatz, den du hast gar nicht so schlecht für den Anfang. So ähnlich habe ich in der Vergangenheit mal eine Datenbank für Produktinformationen für einen Kunden gebaut. Charakterisiere am besten die möglichen Wertetypen (bool, string, int, image, ...) und leite daran daraus die Schlussfolgerungen für das Datenmodell ab. Informationen/Attribute (eines Objektes) die sich gleich verhalten, sollten auch gleich verwaltet werden. :-)
Ciao, Frank
-
Hallo,
danke für die Antwort.
Ich hatte auch schon an ein ODBMS gedacht und mir einige Kandidaten kurz angeschaut (Caché, o4db). Allerdings sind die meisten kommerziell und/oder für Java - bindings für PHP oder Ruby fehlen bei allen die ich gesehen habe. Außerdem bräuchte man natürlich einen dedizierten Server auf dem man die DB-Software installiert, meisten hat man nur SQL-Datenbanken zur Verfügung. Das ist allerdings das kleinere Problem.
Hinzu kommt natürlich das ich mit relationalen Datenbanken die meiste Erfahrung habe.wenn deine DB außer relationalen Tabellen auch noch XML (nativ) beherrscht, würde ich dir empfehlen XML mit XSD (Schemas) zusammen zu verwenden.
Auch das kam mir in den Sinn, vom Design her erscheint mir das fast am vernünftigsten.
Kennst du vielleicht ein paar Links mit Codebeispielen?Grüße,
Peter-
Hallo nochmals,
XML-Datenbanken sind momentan wohl nur in Oracle 8i und neuer implementiert, MS SQL Server 2005 lässt ja bekanntlich auf sich warten, nach dem Motto "Was lange währt, wird gut" ... na wollen wir es mal hoffen.
Von mySQL ist mir solche Funktionalität "nativ" nicht bekannt, aber da wissen andere besser Bescheid. Alles was nicht nativ ist, kostet Performance. Inwieweit dies deine Entscheidung negativ oder positiv beeinflusst, musst du wissen. Auf die Kürze habe ich folgendes gefunden: http://sourceforge.net/projects/phpsqlxml Evt. hilft es dir da weiter.
Unter den Voraussetzungen würde ich dir momentan von einer Vermischung von XML und deinem verfügbaren DBMS abraten (es sei denn, es ist Oracle) , mit dem schon angedeuteten relationen Schema solltest du deine Aufgabe durchaus meistern können.
Gruß, Frank
-
mit dem schon angedeuteten relationen Schema solltest du deine Aufgabe durchaus meistern können.
Ja ich glaub ich bleib auch dabei - mit der Hoffnung das das ganze auch bei vielen Objekten performant bleibt und ich nicht plötzlich über schwierig zu realisierende Anfragen durch dieses Design stoße.
Fürs Archiv hier noch ein Link zu nativen und "enableten" XML-DBs sowie Middleware:
http://www.rpbourret.com/xml/XMLDatabaseProds.htm#products-
Moin,
achte auf richtige Indizierung (covering indices), nur so als Tipp.
In der von mir erwähnten Produktdatenbank liegen aktuell etwa 900 Produkte mit durchschnittlich 6 Attributen (Beschreibung, Bild, Tabelle, Liste, VE, Preis usw.) in 2 Sprachen. Das ganze basiert aktuell noch auf MS Access und VBScript. Es hält der Benutzung im Internet durch täglich 150 Besucher problemlos stand, trotz Access & VBS :-)
Bezüglich Komplexität der Abfragen, ich bediene mich da der MS Technologie des DataShaping (um eine hierarchische struktur aus einer Abfrage in ein Resultset zu bekommen). Wenn man nur Joins ohne Subqueries zur Verfügung hat, könnte es schon etwas komplizierter werden. Aber da ich deine Basis nicht kenne (ich vermute jedoch PHP&MySQL), kann ich dir da auch keine weiterführenden Tipps geben.
Auch wieviele Objekte du letztendlich speichern willst, hast du nicht wirklich gesagt, meine ich mich zu erinnern, lediglich "viele".
Nette Liste, hübsch "vollständig", nebenbei bemerkt. Definitiv eine Bereicherung für das Archiv.
Ciao, Frank
-
Hi,
In der von mir erwähnten Produktdatenbank liegen aktuell etwa 900 Produkte mit durchschnittlich 6 Attributen
Langfristig würden bei mir einige Hundert bis wenige Tausend Objekte liegen - das größere Problem ist jedoch das diese viele Dutzend Eigenschaften haben. Von diesen sind aber natürlich immer nur wenige für die Datenbankabfragen (d.h. in den WHERE clauses) interessant.
Die restlichen werden lediglich dargestellt oder evtl. durch andere Anwendungen weiterverarbeitet. Da böte sich XML (+ XSL) dann schon sehr an. Ein Mittelweg wäre nur die abfragerelevanten Felder in den Tabellen zu speichern und den Rest als reines XML - was natürlich Updates in den anderen Feldern kostspielig macht, außer man verwendet dafür extra ein natives XML-DB. Dann hat man aber 2 Datenbanken und die Gefahr von Inkonsistenzen...
Gar nicht so einfach ;-)MySQL unterstützt seit 4.1 auch glücklicherweise Subselects, allerdings noch keine Stored Procedures (die hier sicher sehr hilfreich wären - kommen wohl in 5.x). Daher tendiere ich momentan eher zu PostgreSQL.
Auch noch fürs Archiv: Die recht populären nativen XML Datenbanken Xindice und eXist lassen sich wohl beide recht einfach über XML-RPC abfragen - man braucht also keine extra Bibliotheken für die jeweilige Programmiersprache - solange man welche für XML-RPC hat. Und das gibts für so ziemlich jede.Grüße,
Peter
-
-
-
-
-