Andreas Korthaus: Welches RDBMS?

Beitrag lesen

Hi Klaus!

Was hälst Du denn von er Idee die Struktur mehr oder weniger persistent in einem PHP-Array zu speichern?

Wenn es brauchbar implementiert ist...;-)

Naja, erst dachte ich dran dass in Javascript zumachen, also den kompletten Array mit der Struktur in einer externen Javascript-Datei zu speichern, das wäre das mit Abstand effizienteste, da die nur einmal übertragen werden muss, da sich die Struktur nur selten ändern wird. Das wird nur problematisch wenn es ein paar mehr Kategorien, und  außerdem müssten alle Produkte da mit rein, das würde dann sehr groß und damit unbrauchbar.

Für die Wartung der Daten ist imho die Tabelle mit den 'Ordnern' und einer jeweiligen Parent-ID am einfachsten. Das Aufbereiten dieser Daten für eine Visualisierung ist dann schon etwas anderes, weil Du wahrscheinlich ausprogrammierte rekursive Abfragen vermeiden willst.

Sicher, daher werde ich das nur machen, wenn sich was ändert. D.h. bei einer Änderung der Struktur werde ich anschließend den mehrdimensionalen Array mit der Struktur neu erstellen, mit der Funktion var_export in eine Datei schreiben, dann habe ich nämlich eine Text-Datei in der sowas steht:

<?php
$struktur = array(
              'Lebensmittel' => array('Molkereiprodukte' => array('Milchprodukte','Quarkprodukte'),
              ...
);
?>

den kann ich dann _durekt_ verwenden(per include), da es sich um PHP-Code handelt.

Daher solltest Du Dir imho überlegen, wie die Daten am besten für die Visualisierung daher kommen sollten. Dementsprechend könntest Du dann beispielsweise bei der Änderung der rohen Strukturdaten schon eine Überleitung in eine passende Darstellungsform implementieren.

Ja, das wäre ja sowas wie mit Javascript, aber da ist halt das Prblem mit der Größe, bei 10.000 Arikeln kann der Array mehrere MB groß sein,  auch wenn ich das komprimiert ausliefere ist das viel zu groß.

Wenn Du also, sagen wir mal, zum Schluß kommst, Daß Dir eine Pfadangabe wie Lebensmittel/Getränke/Milchprodukte für die Darstellung am besten erscheint, dann könntest Du bereits nach dem Schreiben einer Änderung (inklusive Insert) diesen Pfad zusammen bauen und dem entsprechend abspeichern( Wobei das allerdings nicht ganz trivial ist, wenn z.B. ein 'Ordner' verschoben wird).

Daher werde ich die Struktur komnplett neu bauen, bei jeder Änderung, immer basierend auf dem was in der Tabelle der DB steht. Aufgrund der zu erwartenden Größe, werde ich beim klicken auf eine Unterkategorie einen Request an den Server senden, und entsprechend die Einträge für diese Unterkategorie ermitteln. So werde nicht mehr Daten übertragen als notwendig, dafür ist es nicht so schön flüssig wie bei Javascript, naja.

PostgreSQL ist schon wirklich nett

Ich habe mal auf die Schnelle die Dokumentation durchflogen, und das klingt alles recht vernünftig, was da so geboten wird. Daher will ich mir einmal in nächster Zeit das Teil genauer ansehen. Das könnte für ein in Kürze aktuell werdendes Projekt interessant sein.

Ich habe auch nich wirklich vie Erfahrung damit, habe das seit kurzem erst auf meinem Server installiert und stelle gerade von MySQl 4 um.

BTW: mittels der Möglichkeit in PostgreSQL Funktionen in der Datenbank zu schreiben könnte ich mir vorstellen, daß Du eventuell die Daten aus den Struktur-Tabelle auch on-the-fly aufbereiten kannst. WIe performant so etwas sein  wird, kann ich natürlich nicht sagen.

Hm, muss ich mal sehen, aber da ich das eh nicht on-the-fly machen werde habe ich damit weniger Probleme, und ich vermeide das dann doch lieber, falls ich dann mal auf eine andere RDBMS(DB2...) umstellen müsste, dann habe ich mit solchen Sachen nämlich größere Probleme.

Wie/ob man auf Firebird aus PHP zugreifen kan weiß ich nicht,
Afaik wird Firebird direkt untestützt, wie gut diese Unterstützung ist, kann ich mangels PHP-Erfahrung nicht sagen.

Ja, da sgeht glaueb ich über dei Interbase Funktionen, ich hoffe nur nicht das an der Interbase-API was verändert wurde. Nur hätte ich da wohl eher ein problem ein Produkt was gerde frische neu Programmiert wurde einzusetzen. Sicher ist es jetzt schneller, aber da sind zwangsweise noch sehr viele Fehler drin, und das ist das letzte was ich brauche, die Performance ist zwar nicht unwichtig, aber im Vergleich zu solchen Problemen eher vernachlässigbar. Das Problem sehe ich auch bei SAP DB, was ich da so gelesen habe, ist das doch schonmal recht instabil. Vermutlich ist das ähnlich bei bei Oracle, dass man das durchaus sehr stabil hinbekommt, aber dazu braucht man echte Experten, SAP empfiehlt ja auch dass man unbedingt für 60.000 USD den Support mitbestellen soll, will man es produktiv einsetzen. Das ist der Vorteil von MySQL, das ist wirklich sehr einfach und gut dokumentiert, dass man damt schon alleine klarkommt, wie das bei PostgreSQL ist muss ich aber erst noch sehen. Und auch bei DB2 und Co. weiß ich nicht wie unkompliziert die sind, aber vermutlich eher in Richtung Oracle als in Richtung MySQL.

nur tue ich mich immer schwer mit ODBC, damit hatte ich schonmal arge Probleme, und das unter Windows wo es ja eigentlich herkommt.

ODBC an sich ist, so finde ich, nicht schlecht. nur sind die Treiber für die einzelnen Datenbanken teilweise ziemlicher Mist.

Ja, genau das ist es, native CLI's sind mit da erheblich lieber.

Viele Grüße
Andreas