Datenbankfrage XML or Mysql?

[$tormer]

Servus allerseits,

ich plane ein groesseres verwaltungsscript zu proggen, bassierend auf php und einer datenbank. es geht um einen modularen aufbau wie buchhaltung,billing, support, servermonitoring etc. ...
nun muss ich vorab einiges planen wie z.b den datenbanktyp.

daher meine frage was aus eurer sicht am sinnvollsten waere zu benutzen. persoenlich wuerde ich eher mysql waehlen, da ich weis damit umzugehen, jedoch scheint xml auch eine gute variante fuer ein dynamisches system zu sein.

bitte um ein paar comments bezueglich speed, security, programmierungs-aufwand etc. :) um einen generellen ueberblick zu bekommen und andere meinungen zu hoeren :)


vielen dank im voraus fuer eure posts ;)

[henock]

Moin,

also im Falle von PHP würde ich auf jeden Fall eine Datenbank verwenden und nicht mit XML-Dateien arbeiten. Mit PHP wirst du dein Programm ja kaum persistent geladen halten, sondern es wird zwischen den Requests immer wieder neu gestartet. Ergo müsste dein Skript dann auch bei jedem Request zunächst mal das XML-Doc. parsen. Und das kann dann ganz schön auf die Performance drücken (besonders wenn du nicht gerade das 0815 "Tante-Frieda-Gästebuch" schreiben willst). Ferner bietet dir XML keine vernünftige Auswertung an, du müsstest dir also alle Ergebnisse (Summen, Mittelwerte usw.) "per Hand" berechnen. Und auch das kann PHP 100%ig nicht so schnell wie ein nativer DB-Server. Und vom nachproggen von 1:n und n:m Beziehungen in XML und PHP wollen wir nu erst gar nicht anfangen..... ... und ganz zu schweigen von den klassischen Problemen bei Schreib/Lesezugriffen auf deine XML-Dateien wenn mehr als ein Anwender deine Skripte benutzt.

Also wenn PHP, dann würd ich auf jeden Fall ne richtige DB nehmen. Anders könnte es beim Programmieren einer persistenten Lösung sein, z.B.: bei Schaffung einer J2EE Middleware o.ä.

Bei der Datenbank würde ich auch nicht zu tief stapeln, wenn du tatsächlich Buchhaltung etc. implementieren willst, dann ist 100% eine DB mit Views sinnvoll (PostgresSQL). Und wenn deine Buchhaltung dann auch noch sensible Daten enthält wäre hier ein DB-Server mit ausgefeilter Bentzerverwaltung bis auf Spaltenlevel sinnvoll (?Interbase/Firebird).

Just my 2 cents....

[oxygen]

Wenn es um Buchhaltung geht, halte ich vorallem Transactions für unerlässlich, aber die kann MySQL ja mittlerweile. Im Prinzip eine Glaubensfrage ob MySQL oder PostgreSQL. Bei MySQL hast du natürlich den Vorteil, das es viel weiter verbreitet ist und eine sehr hohe Performance hat. PostgreSQL dagegen implementiert dafür den SQL Standard kompletter. XML halte ich dagegen auch für wenig sinnvoll. Einfach (noch) zu schwer zu handlen.

[arty]

Einfach (noch) zu schwer zu handlen.

XML ist nicht schwer zu handlen!

bye
arty

[dodolin]

XML ist nicht schwer zu handlen!

Das hängt sehr von den Vorkenntnissen ab. Ansonsten ACK.

[majortermi]

XML ist meiner Erfahrung nach sehr gut für Daten geeignet, die sich eher selten ändern bzw. die keine Datenbankstruktur haben. Beispiele dafür sind Konfigurationsdateien, oder der Aufbau der Navigation. Ich würde dir allerdings eher zur Verwendung von Java Servlets raten, da hier die Persistenz von Sessions sowie das Sharing von nicht Session-bezogenen Daten wesentlich besser gelöst ist.

[oxygen]

XML ist nicht schwer zu handlen!

Das hängt sehr von den Vorkenntnissen ab. Ansonsten ACK.

und von der Art den Anwendung. Wenn es z.B. um RSS geht, bin ich schon recht fit in XML, aber eine Buchhaltung die als Backend XML verwendet, ist deutlich schwerer umzusetzten als mit SQL.

[$tormer]

erstmal vielen dank fuer die antworten :)
ich persoenlich halte es auch fuer einfacher datenbank fuer mysql oder postgressql wobei ich mit dem 2teren noch nicht gearbeitet habe.
geplant ist das verwaltungs script auf mit einem webmodul zu koppeln fuer verwaltung und dynamische aktualisierung etc. wofuer sich eventuell xml fuer den inhalt zb. text, agb usw. eigenen wuerden. ist eine kombination von postgres sql also datenbank fuer dynamische/wechselnde inhalte und xml fuer den anderen typ zu empfehlen oder besser auf das eine oder das andere spezifizieren?
zum thema java servlets habe ich leider gar kein ahnung. bin zwar am ueberlegen java zu lernen jedoch liegt mir php sehr viel mehr.
welche vorteile wuerden java servlets mitbringen? ausser sessions und deren sharing prozess? es geht auch darum das ganze so modular wie moeglich zu halten, sodass man module weglassen kann, die nicht benoetigt werden.
bezueglich datensicherheit, es wird warscheinlich auf einem seperaten server hinter 1-2 routern und sicherheitsmechanissmen laufen, wird sehr warscheinlich im web verfuegbar sein, da ich sehr viel reise und gelegentlich in anderen locations/laendern bin. der server/ die server sind geplant nur fuer diese aufgabe. eventuell werde ich dienste wie DB und webserver splitten, sodass nur indirekter zugang auf den datenbank server moeglich ist, und der andere "webverarbeitende" server drauf connected und sich die daten holt.

fuer weitere ideen bin ich sehr offen :)

[henock]

Hmmmm....
....Vorteile von Java gegenüber PHP, wo fangen wir denn da an...

- Die Sprache ist wesentlich strenger typisiert als PHP, vermeidet Fehler bzw. deckt fehler schon beim Kompilieren auf.
- Java ist eine "richtige" OOP-Sprache. D.h.: nicht so ein habnherziges Kinderkrams OOP wie bei PHP, sondern man hat alles was das Herz begehrt (beispielsweise Interfaces und mehrfach Vererbung)
- Bei Verwendung der passenden Mechanismen (J2EE, aufbau einer 3 oder 4 schichtigen Architektur des Gesamtkunstwerks) kann man persistenz erreichen und die Darstellungsschicht von der Geschäftslogik trennen, sowie die Datenhaltung aus beiden anderen Schichten halten. Das erleichtert die Pflege und Erweiterung der Anwendung enorm
- Aus diesen (und vielen kleinen anderen Gründen) ist JAVA gerade für den Enterprise-Bereich mit PHP nicht zu vergleichen, da ist PHP mehr oder minder ein kleines Häufchen Schrott. Sorry, aber so ist das. Ich habe auf der Spitze des PHP Hypes mehrere grössere Multi-User Anwendungen für Forschung und Industrie entwickelt, und dort zeigten sich dann mehr und mehr die Nachteile von PHP.
- Gute Unterstüzung für verteiltes Rechnen/Clustering
- Einheitliche DB-Anbindung

Nachteile von Java gegenüber PHP:
- Deutlich steilere Lernkurve als bei PHP
- Etwas kompliziertere Administration/Enrichtung der Serverumgebung
- Nicht so gut für Quick&Dirty Lösungen geeignet.

Bzgl. der Geschwindgkeit liegen beide Lösungen mindestens gleich auf (wenn man z.B.: PHP mit JSPs vergleicht), seit Einführung der HotSpot-Technologie würde ich hier sogar bei Java einen Geschindigkeitsvorteil gegenüber PHP sehen.

[arty]

Bzgl. der Geschwindgkeit liegen beide Lösungen mindestens gleich auf (wenn man z.B.: PHP mit JSPs vergleicht), seit Einführung der HotSpot-Technologie würde ich hier sogar bei Java einen Geschindigkeitsvorteil gegenüber PHP sehen.

Das kann ich nicht so bestätigen. Ich habe mal eine Testsuite geschrieben, bei der einmal per PHP und einmal über JSP und JavaBeans Daten von einer DB2 Datenbank abgefragt wurde. Dabei war PHP auf Windows2000 und Linux immer schneller als Java.

Unter Linux wars auch schneller als unter Windows.... 8)

bye
arty

[majortermi]

Das kann ich nicht so bestätigen. Ich habe mal eine Testsuite geschrieben, bei der einmal per PHP und einmal über JSP und JavaBeans Daten von einer DB2 Datenbank abgefragt wurde. Dabei war PHP auf Windows2000 und Linux immer schneller als Java.

Unter Linux wars auch schneller als unter Windows.... 8)

Da würden mich doch mal die genaueren Testbedingungen interessieren. Gibt es den Code der PHP- und Java-Lösung ingendwo?

Ich vermute, dass entweder der Java-Code vom Design her ineffizient ist, oder das Beispiel tatsächlich so "flach" ist, das PHP etwas schneller arbeitet (was ja nur bestätigen würde, das PHP für einfache Anwendungen durchaus zu gebrauchen ist).

[arty]

Hi Major,

leider hab ich den Code nicht mehr, da ich das vor knapp 2 Jahren im Praktikum programmiert habe. Der Code war bei beiden Lösungen sehr knapp gehalten, also bei PHP zB keinerlei Klassen oder DB-Abstraktion, sondern Zugriff auf die direkten PHP-Funktionen. Bei den Beans war es genauso.

Im übrigen war auch MySQL 4.0 alpha damals bedeutend schneller als die DB2, selbst bei hunderttausenden abgefragten Datensätzen.

bye
arty