nicht angemeldet
MySQL vs. XML
Hallo,
Diesem Posting geht eigentlich ein Thread weiter unten voran in dem etwas über ein XML -Schema gefragt wurde , das mit einem php-skript funktionieren soll (Userzugangsmanagment), weil keine Datenbank zu Verfügung steht. Jetzt wüßte ich ja doch mal gerne was die Allgmeinheit hier davon hält. Ich meine so gut und so flexibel XML ist, aber für so eine Anwendung ist es doch völlig non-performant , oder ? Ich meine wenn ich als client das php-skript starte, muß ich doch jedesmal erst die gesamte Datei einlesen (...ich gehe davon aus daß auf dem Server kein program läuft , daß die Daten schon eingelesen zu Verfügung stellt) und taggen bevor ich was damit anfangen kann, und da das ja alles Zeichenkettenoperationen sind ist das doch ewig langsam. Habe ich einen Service laufen der mir die Daten einmal einliest und dann jedem skriptaufruf die Daten sofort zur Verfügung stellt dann sehr fein weil schneller als Datenbank, habe ich das nicht ist es doch von der Performance noch mieser als flatfiles , oder sehe ich da was falsch ?
Gruss
Peter , der für den bruchteil einer Sekunde daran dachte seine Datenbank auf XML umzustellen...:-)
-
yo,
mit XML kenne ich mich leider nur wenig bis gar nicht aus. aber in aller regel laufen solche diskussionen darauf hinaus, dass man versucht, das eine oder andere als generell besser darzustellen. in der IT welt ist es aber meistens so, dass es keine pauschalen aussagen gibt, sondern man von fall zu fall klären muss, was gerade das bessere für eine spezielle situation ist.
insofern macht es in meinen augen wenig sinn, mysql mit XML zu vergleichen. beide haben ihre vorteile und schwächen und je nachdem was du machen willst, benutzt man das eine oder das andere.
Ilja
-
insofern macht es in meinen augen wenig sinn, mysql mit XML zu vergleichen. beide haben ihre vorteile und schwächen und je nachdem was du machen willst, benutzt man das eine oder das andere.
Ja das ist mir schon klar, ich würde auch für komplizierte Datenformate auf jeden Fall XML vorziehen, aber genau um diese Diskussion zu vermeiden die ins uferlose führen mussm habe ich ja ein konkretes Beispiel angegeben : XML in Verbindung mit PHP bzw. Skriptsprachen ohne ein "singleton" objekt was mir die Daten auf dem Server eingelesen zur Verfügung stellt. Es geht darum, daß in den Fällen, gerade mit Skriptsprachen , diese Datenstrukturen jedesmal eingelesen werden müssen (sei mal von irgendwelchen Sessionspeicherungen abgesehen, die ja doch irgendwie fischig sind) und das ja nunmal absolut langsam ist im vergleich zu einer relationalen Datenabnk...
-
-
Moin,
Ich meine so gut und so flexibel XML ist, aber für so eine Anwendung ist es doch völlig non-performant , oder ?
Kommt würde ich sagen sehr darauf an, wieviele Benutzer deinen Web-Service nutzen und für welche Zwecke du die Userdaten brauchst (außer fürs An- und Abmelden und Session-Management).
Falls Du die Daten ggf. auch für andere Dienste brauchst (Userstatistiken usw.) und solange Du nicht zu viele Benutzer hast, wäre es schon zu überlegen,ansonsten macht ein DBS mehr Sinn.Grüße,
Jörg-
Falls Du die Daten ggf. auch für andere Dienste brauchst (Userstatistiken usw.) und solange Du nicht zu viele Benutzer hast, wäre es schon zu überlegen,ansonsten macht ein DBS mehr Sinn.
...aber das kann doch nicht der Sinn des Ganzen sein, für ganz kleine Usermengen xml zu verwenden und sollten es mehr werden muß ich umsteigen...von der Skalierbarkeit des Systems her doch ein faux-pas ...
-
Hi,
Falls Du die Daten ggf. auch für andere Dienste brauchst (Userstatistiken usw.) und solange Du nicht zu viele Benutzer hast, wäre es schon zu überlegen,ansonsten macht ein DBS mehr Sinn.
...aber das kann doch nicht der Sinn des Ganzen sein, für ganz kleine Usermengen xml zu verwenden und sollten es mehr werden muß ich umsteigen...von der Skalierbarkeit des Systems her doch ein faux-pas ...
richtig, fuer das Implementieren von Sicherheit mit XML(-Dateien z.B.) zu kommen, ist ungewoehnlich. Da ist doch ein RDBMS mit den Tabellen 'User', 'Rights' und 'Sessions' angesagt.
BTW - so weit ich weiss ist das Forum hier groesstenteils XML-basiert. Da liegen also so XML-Dokumente im Speicher und im FS. (Ich wuerde es nicht so machen. ;-)
XML-Datenhaltung, also objektorientierte Datenhaltung empfehle ich dann, wenn strukturierte Daten ausgetauscht und gespeichert werden muessen, deren Struktur sich aber immer wieder zu stark aendert, um im RDBMS nachgegossen werden zu koennen. (Material fuer Kataloge faellt mir da so ein, also z.B. ein XML, das einen Toaster darstellt und eins, dass einen Porsche darstellt. Entsprechende Schma-Dateien vorausgesetzt.)
Gruss,
Ludger-
Hallo, Ludger!
BTW - so weit ich weiss ist das Forum hier groesstenteils XML-basiert. Da liegen also so XML-Dokumente im Speicher und im FS. (Ich wuerde es nicht so machen. ;-)
ja, das wissen wir ja nun. und das du immer noch darauf herumreitest, zeigt doch nur, dass du immer noch nicht kapiert hast, dass diese lösung schneller arbeitet, als dein geliebtes rdbms. aber fasel ruhig weiter, scheisserle, wir können das ertragen. ;-)
freundl. Grüsse aus Berlin, Raik
-
yo,
ja, das wissen wir ja nun. und das du immer noch darauf herumreitest, zeigt doch nur, dass du immer noch nicht kapiert hast, dass diese lösung schneller arbeitet, als dein geliebtes rdbms.
nur mal interesse halber, ist denn dafür ein parallel test gelaufen XML vs RDBMS ?
Ilja
-
Hallo, Ilja!
ja, das wissen wir ja nun. und das du immer noch darauf herumreitest, zeigt doch nur, dass du immer noch nicht kapiert hast, dass diese lösung schneller arbeitet, als dein geliebtes rdbms.
nur mal interesse halber, ist denn dafür ein parallel test gelaufen XML vs RDBMS ?meines wissens hat ck das getestet und wenn ich mir überlege, dass er ein programm schreibt, welches auf _genau_die_ aufgaben hier im forum _spezialisiert_ ist, die daten dazu _selbst_ im speicher vorhält, statt erst einem anderen programm ne anfrage zu schicken, welches zwecks allgemeiner verwendbarkeit natürlich komplexer wäre und mehr ram verbrauchen würde, dann überzeugt mich schon diese überlegung davon, dass ck's lösung schneller ist.
es ist aber ein hobby von ludger, den devs hier ständig wissenslücken und die notwendigkeit von weiterbildung (durch ihn?) zu unterstellen.
ausserdem hat er wohl auch einen narren an der bezeichnung "rdbms" gefressen und schlägt das für fast jede frage als lösung vor, wo es irgendwie hinpassen könnte.freundl. Grüsse aus Berlin, Raik
-
yo,
wenn ich das nun richtig zwischen den zeilen lese, dann hat man es noch nicht auf einem rdbms implementiert, sondern nur im vorfeld überlegungen gemacht, welche lösung besser wäre ?
Ilja
-
Hallo, Ilja!
yo,
wenn ich das nun richtig zwischen den zeilen lese, dann hat man es noch nicht auf einem rdbms implementiert, sondern nur im vorfeld überlegungen gemacht, welche lösung besser wäre ?
< http://forum.de.selfhtml.org/archiv/2004/9/t89740/#m539969> mal zum nachlesen, da gehts um das thema.
(also sowohl rdbms vs. xml, als auch lude/ludger)
da müsste auch irgendwo was zum vergleich der beiden lösungen dabeistehen.freundl. Grüsse aus Berlin, Raik
-
yo,
da müsste auch irgendwo was zum vergleich der beiden lösungen dabeistehen.
habe nicht alles gelesen, das war mir ein wenig zu emotional. ich persönlich ziehe eigentlich auch sehr gerne RDBMS in betracht, weil sie eben so schön flexibel und dynamisch sind, sprich eine grosse "zukunftssicherheit" bieten. gerade für firmen, wo sich schnell mal was ändert, ist meiner meinung so etwas besser als spezielle insel-lösungen. performance ist halt nicht alles, ansonsten würde wir ja alle in assembler programmieren müssen. ;-)
ausserdem macht man sich nicht von einem programm/datenstrukur so stark abhängig. aber ich habe bis jetzt auch keine arbeit in das projekt selfhtml reingeteckt, ausser hier und da mal einen tipp abzugeben. insofern sollten die macher darüber entscheiden, was für sie am besten ist. den ohne sie, würde es kein selfhtml geben.
ich glaube, bei diesem thema ducke ich mich lieber, als in ein wespennest meine nase reinzustecken.
Ilja
-
Hallo, Ilja!
ich persönlich ziehe eigentlich auch sehr gerne RDBMS in betracht, weil sie eben so schön flexibel und dynamisch sind, sprich eine grosse "zukunftssicherheit" bieten. gerade für firmen, wo sich schnell mal was ändert, ist meiner meinung so etwas besser als spezielle insel-lösungen. performance ist halt nicht alles, ansonsten würde wir ja alle in assembler programmieren müssen. ;-)
ich arbeite gern mit flatfiles, solange das von der datenmenge her vertretbar ist. da lese ich die daten direkt in arrays ein, mit denen ich dann weiterarbeiten kann. zum schluss wird einfach alles zurückgeschrieben.
hat den vorteil, dass es auch ohne db-server läuft, b.z.w., wenn der grad mal busy ist.
ausserdem kann man seine daten einfach als datei runterladen. das klartextformat ist halt im zweifel auch leichter zu reparieren, als eine richtig gecrashte datenbank.
wenn natürlich die beziehungen zwischen den daten sehr komplex sind, oder die datenmenge sehr gross ist, ist ein rdbms die bessere wahl.wer meint, ck's lösung wäre nicht optimal, der soll halt seine testergebnisse vorlegen, aber substanzloses meckern, wie von lude/ludger ist inakzeptabel.
freundl. Grüsse aus Berlin, Raik
-
yo,
wenn natürlich die beziehungen zwischen den daten sehr komplex sind, oder die datenmenge sehr gross ist, ist ein rdbms die bessere wahl.
wenn ich das pro und kontra betrachte, wann dbms zu benutzen sind, dann haben dbms einen entscheidenen vorteil, nämlich dynamik. und diese dynamik, bzw datenunabhängigkeit überwiegt meiner meinung nach andere gründe wie zum beispiel performance, zumal durch die schnittstelle des dbms sich weitere optimierungsmöglichkeiten anbieten. im profigeschäft haben sich eigentlich datenbanken durchgesetzt und das ist ein pro argument für rdbms. mich würde es wundern, wenn firmen noch auf flat files aufsetzen würden. aber das ist sicherlich meine persönliche ansicht und ausnahmen bestätigen die regel.
wer meint, ck's lösung wäre nicht optimal, der soll halt seine testergebnisse vorlegen, aber substanzloses meckern, wie von lude/ludger ist inakzeptabel.
ck's fähigkeiten übersteigen sicherlich die meinen. und sein brot ist nur der ruhm und die ehre, quasi for nothing. aber es war ja umgekehrt der fall, dass gesagt wurde, das jetzige forum ist optimaler gegenüber einer lösung mit rdbms. ich wollte halt nur mal nachfragen, ob die beiden systeme real nebeneinander getestet wurden. und dies scheint nicht der fall zu sein, sondern überlegungen im vorfeld haben eine vorauswahl getroffen.
Ilja
-
-
Hi,
ich glaube, bei diesem thema ducke ich mich lieber, als in ein wespennest meine nase reinzustecken.
es ist immer sehr problematisch, wenn sich Architekten/Entwickler mit ihrer Loesung bzw. ihrem Produkt dermassen identifizieren, dass sachliche Kritik persoenlich genommen wird. Allerdings erlebe ich das auch in meinem Job regelmaessig (allerdings immer seltener).
Ist das aber der Fall, dann wird der Kritisierende mit einem sozialen Druck konfrontiert, der nicht einfach zu bearbeiten ist. Falsch sind dann mindestens zwei Sachen:
1.) die Diskussion aus Konfliktscheue meiden (Es gibt dann Folgetaeter, die "Kultur" geht den Bach runter und auf einmal duerfen alle alles sagen. Und die Entscheider, die in der Regel nicht so nah am eroerterten System dran sind, sind irritiert)
2.) bedingungslos eskalieren, weil man recht hatVermutlich ist der Mittelweg "des gelegentlichen Erinnerns und Ansprechens" auch der Koenigsweg. Mit einigem zeitlichen Abstand kann man dann die eigene Meinung bzw. (haeufiger ;-) die Meinung des "Kritikopfers" (so fuehlt es sich oft) anpassen.
Dennoch sind die Poebeleien von raik natuerlich durch nichts zu entschuldigen.
Gruss,
Ludger
-
-
-
-
-
-
-
Hallo,
richtig, fuer das Implementieren von Sicherheit mit XML(-Dateien z.B.) zu kommen, ist ungewoehnlich.
Ja, aber (mittlerweile) nicht so abwägig. XML Encryption und XML Signatur gehen genau in diese Richtung. Natürlich bedürfen beide eine entsprechende Softwareumgebung.
Ich bin mir auch nicht sicher ob bei dieser Frage XML die richtige Lösung ist, denn zumindest würde ich die Passwörter nicht in Klartext notiert haben wollen.Grüße
Thomas
-
-
-