Listen und Schemas in relationalen Datenbanken (=SQL)

[damianh]

Hallo liebe Forumsnutzer, ich habe folgende Frage an euch:

Ich möchte eine Datenbank für Lebensmittel erstellen. Da hier oft Listen vorkommen (e.g. Zutaten: ["Wasser", "Mehl", "Salz"]) dachte ich zuerst an eine Implementierung in XML. Zudem bietet XML die Möglichkeit seinen Inhalt mit Schemata (.xsd) zu überprüfen. (e.g. die Liste darf nur vorgegebene Zutaten enthalten (d.h. "Wasser" und "Mehl" sind ok, "Waser" oder "Karton" nicht); oder der Zuckeranteil muss zwischen 0 und 100 liegen).

XML Datenbanken werden aber, wenn sie wachsen und sehr gross werden immer langsamer und ineffizienter. Dshalb wollte ich fragen:

Gibt es eine SQL Lösung, die 1. Listen und 2. Restriktionen in Tabellen unterstützt?

Ansonsten würde ich wohl eine Methode wählen, die die XML Datenbank in eine relationale Datenbank konvertiert um dann schneller Abfragen zu können.

Vielen Dank für jeglichen Input
Gruss Damian

 

[akretschmer]

Hallo liebe Forumsnutzer, ich habe folgende Frage an euch:

Ich möchte eine Datenbank für Lebensmittel erstellen. Da hier oft Listen vorkommen (e.g. Zutaten: ["Wasser", "Mehl", "Salz"]) dachte ich zuerst an eine Implementierung in XML. Zudem bietet XML die Möglichkeit seinen Inhalt mit Schemata (.xsd) zu überprüfen. (e.g. die Liste darf nur vorgegebene Zutaten enthalten (d.h. "Wasser" und "Mehl" sind ok, "Waser" oder "Karton" nicht); oder der Zuckeranteil muss zwischen 0 und 100 liegen).

XML Datenbanken werden aber, wenn sie wachsen und sehr gross werden immer langsamer und ineffizienter. Dshalb wollte ich fragen:
Gibt es eine SQL Lösung, die 1. Listen und 2. Restriktionen in Tabellen unterstützt?

Ansonsten würde ich wohl eine Methode wählen, die die XML Datenbank in eine relationale Datenbank konvertiert um dann schneller Abfragen zu können.

Vielen Dank für jeglichen Input
Gruss Damian

Also die erlaubten Zutaten z.B. könntest Du über Nachschlagetabellen lösen. Aber dann noch so Restriktionen wie Anteil zwischen 0 und 100% für Zucker oder so wird dann schon schwerer. Du müßtest ja auch alle Restriktionen definieren.

Was es auch gibt sind so Dinge wie HSTORE, also Key-Value-Datentypen. Mal so als Demo:

test=# create table lebensmittel(id serial primary key, name text, zutaten hstore);
CREATE TABLE
Time: 31,049 ms
test=*# insert into lebensmittel values (default, 'bier', 'wasser => "10 Liter", Hopfen => "1kg", Malz => "5kg"'::hstore);
INSERT 0 1
Time: 0,465 ms
test=*# insert into lebensmittel values (default, 'brot', 'wasser => "10 Liter", Mehl => "5kg", Salz => "1 Prise"'::hstore);
INSERT 0 1
Time: 0,222 ms

Angenommen, Du willst nun wissen, wo Salz drin ist:

test=*# select * from lebensmittel where zutaten ? 'Salz';
 id | name |  zutaten
----+------+--------------------------------------------------------
  2 | brot | "Mehl"=>"5kg", "Salz"=>"1 Prise", "wasser"=>"10 Liter"
(1 row)

Das geht auch recht flott, PG speichert das binär und kann da auch mit Indexen drauf suchen. Ich könnt mir vorstellen, daß man z.B. via TRIGGER beim Insert auch prüft, daß da nur erlaubte Keys eingefügt werden.

Du kannst natürlich auch beim guten, alten Design mit z.B. EAV-Tabellen bleiben, Du kannst diese dann auch als XML oder direkt als JSON ausgeben.
Also, machbar ist vieles, nur mit den unterschiedlichsten Constraints wird es schwer, aber nicht unmöglich - über TRIGGER z.B.

Du solltest aber gleich eine DB nehmen, die Constraints auch einhält...

 

[ukulele]

Ich würde eine Tabelle Zutaten machen mit einem FK auf Lebensmittel, Bezeichung der Zutat, Menge, Einheit und die Restriktionen per Trigger umsetzen. Ist sicherlich ein bischen Arbeit aber hat auch seine Vorzüge.

 

[damianh]

Vielen Dank für Euro Antworten.

Im Moment tendiere ich dazu ein Programm zu schreiben, das eine XML Datei auf ein relationales Datenbankmodell umschreibt. So ist die Eingabe zusätzlicher Produkte auch für Laien möglich (keine Eintragungen auf mehreren Tabellen nötig, sondern leicht verständlicher XML Code der mit Schemata gleich validiert werden kann) und die Abfrage über die generierten SQL Tabellen schnell (ev. gehts dann mit sortierten Tabellen und Indices noch viel schneller).

Eigentlich könnte man die XML Datei auch durch eine Eingabemaske oder ein bestimmtes Eingabeformat ersetzen. Ich weiss eigentlich auch nicht weshalb ich so XML fixiert bin im Moment. Vielleicht weil ich das einfach besser kenne. Um den Hinweis mit den Trigger und HSTORE bin ich auf alle Fälle sehr Dankbar!

 

[ukulele]

Ich könnte ein einfaches Programm für einen XML Import brauchen, leider kenne ich mich damit nicht sehr gut aus

MSSQL bietet die Möglichkeit XML auszugeben aber ich habe noch keinen Weg gesehen auf eine XML Datei aus TSQL zuzugreifen, das wäre echt nützlich in meinem Fall.

 

[damianh]

Das ist eben nicht so trivial, denn XML Daten haben eine andere Struktur als SQL Daten:

SQL = Relationales Datenbankmodell = Mehrere "flache" Tabellen, verlinkt mit Schlüsseln
XML = Baumstruktur = Verschachtelte hierarchische Daten, jeder Knoten kann Werte enthalten

Wikipedia hat hier ein einfaches Beispiel, wie XML Dateien mit SQL, resp. XQUERY (= SQL für XML) abgefragt werden können: http://en.wikipedia.org/wiki/FLWOR

Ich denke allerdings, dass Du bei komplexen, schlecht strukturierten XML Dateien Probleme bekommen wirst, da die Abfrage dann einfach zu kompliziert wird... Habe aber keine Erfahrung damit...

 

[ukulele]

Ich hatte in der Vergangenheit einen Fall bei dem es um Jahresabschlussinformationen im XBRL Format ging. Diese sind sehr umfangreich, beinhalten aber ein paar Felder die eigentlich immer vorkommen müssten. Diese Kennzahlen zu extrahieren wäre interessant. Dazu gibt es jede Menge Anwendungen die aber eher in andere Richtigungen gehen als schlicht 5 Kennzahlen zu extrahieren.

Der Fall ist aber nicht mehr aktuell, vieleicht setze ich mich damit in 2 Jahren nochmal auseinander...