nicht angemeldet
Datenstruktur-Problem / Performance vs. saubere Struktur?
0 0 0 0 0 0
Datenstruktur-Problem / Performance vs. saubere Struktur?
Hallo!
Mal wieder ein kleines Daten-problem ;-)
ich habe eine Art Formular-genrator gebastelt. Das funktioniert so dass man sich damit ein Formular zusammenklicken kann, z.B. kann man ein <select>-Feld erzeugen, indem man die zur Auswahl stehenden <option>'s einträgt, dann kann man einfache Text-Eingabefelder erzeugen, Checkboxen, Upload-Feld... halt die komplette Bandbreite. Das Problem was ich jetzt habe - 1. wie speichere ich diese Angaben möglichst effizient, und 2. wie speichere ich entsprechend die Daten die Anwender später in das so generierte Formular eintragen?
Mein Problem hierbei, ich habe 10 verschiedene Eingabefeld-Typen(select, upload, text...), wovon die meisten anders-artige Daten speichern müssen, aber oft gibt es nur wenige Ausnahmen von der "normalen" Struktur.
Als erstes bilde ich mal den kleinsten gemeinsamen Nenner, also Fragebogen_ID, Feld_ID, Frage(die Antwort darauf wird in das generierte Feld eingetragen) und ob es ein Pflichfeld ist, das speichere ich ich in "fields". Das reicht dann schon für Typen wie "text", "mehrzeiliger text", "upload". Anders bei "select", da muss ich die Auswahlwerte speichern. Und da es da nicht nur einen gibt habe ich eine 1:n Beziehung, also habe ich die Tabelle "fields_select" mit Feld_ID und option, vielleicht noch selected. Anders bei einem "ja/nein" Feld, da speichere ich nur ob ja oder nein vorbelegt ist, noch was anders beim Datum/Zeit-Feld, da speichere ich ob Tag? Monat? Jahr? Stunde? Minute? abgefragt werden soll, bräuchte ich im Prinzip 5 Spalten die ich entweder auf true oder false setze. Und das war noch nicht alles ;-)
Naja, das nächste Problem ist jetzt, wie speichere ich die Daten wenn jemand das oben generierte Formular ausfüllt? Das würde ich eigentlich gerne alles in einer Tabelle speichern, also Tabelle "data" mit User_ID Feld_ID, und "eingabe", nur ist das wieder nicht so einfach, es gibt da ja das mehrzeilige Textfeld, was den Datentypen TEXT erfordert, also alles als TEXT speichern? Das ist auch nicht wirklich effektiv, oder? Weiteres Problem, wenn ich bei select Mehrfachauswahl zulasse, habe ich hier eine 1:m Relation zw. Benutzer und Eingabe, aber auch nur für diesen einen Typen. Also fahre ich wieder 2-gleisig? Alle Sonderfälle raus, und nur die die alle meinetwegen mit 1:1 Relation und CHAR(32) klarkommen sollen in diese Tabelle, der Rest hat eine eigene? Oder für jeden Typen eine eigene Tabelle?
Auf der anderen Seite, CHAR(32) ist sicherlich auch nicht gerade kleiner als TEXT, denn der Speicherplatz ist hier abhängig von der Datenmenge, und da ich nicht nach diesem Feld filtern werden, sondern nur auslese, ist das doch eigentlich gar nicht so schlimm alle Eingaben in TEXT zu speichern, oder? Also Speicherplatzprobleme habe ich sicherlich nicht, eher Performance-Probleme.
Das hatte ich zunächst auch für die Feldtypen überlegt, und dann die Daten (die sonst in eine eigene Tabelle müssten) als serializierten Array zu speichern, nur kann ich die Daten dann natürlich vergessen wenn ich die später anders verwenden will, oder?
Mein Problem dabei ist auch, wie frage ich das ab? Nicht dass ich das nicht könnte, nur darf ich - wenn ich für jeden Typen eine extra Tabelle habe immer erst abfragen welcher Typ, und dann für _jedes_ Feld eine extra-Abfrage auf die eigene Tabelle, selbiges dann bei den eingegebenen Daten. Das heißt ich muss in der Anwendung ne ganze Menge(für meinen Geschmack zu viel) über die Datenstruktur wissen, nur mal so als Beispiel:
Das Formular hat 10 Eingabe-Felder, 2 mehrzeiliche Textfelder, 2 Datumsfelder, 2 Celect-Felder, und 4 einzeilige Textfelder.
Dann muss ich zum erstellen des Formulars etwa wie folgt vorgehen:
$result = SELECT pyp, pflicht, frage FROM fields WHERE fragebogen_ID = $id
foreach ($result) {
if(typ = select) {
SELECT options FROM fields_select WHERE feld_ID = $fid
}
if(typ = date) {
SELECT day,month,year,hour,minute FROM fields_date WHERE feld_ID = $fid
}
...
}
Entsprechend kompliziert geht das ganze mit dem Auslesen bzw. Eintragen von Eingaben die im Formular getätigt wurden. Im Augenblich sehe ich eigentlich keinen besseren Weg, aber vielleicht hat ja jemand eine Idee wie man sowas besser machen kann - wenn Ihr denn versteht was ich meine ;-)
Grüße
Andreas
-
Hi,
(DATENBANK) Datenstruktur-Problem / Performance vs. saubere Struktur?
das hoert sich komisch an, denn eine "saubere Struktur" sollte doch unbedingt erreicht werden.
ich habe eine Art Formular-genrator gebastelt. Das funktioniert so dass man sich damit ein Formular zusammenklicken kann, z.B. kann man ein <select>-Feld erzeugen, indem man die zur Auswahl stehenden <option>'s einträgt, dann kann man einfache Text-Eingabefelder erzeugen, Checkboxen, Upload-Feld... halt die komplette Bandbreite. Das Problem was ich jetzt habe - 1. wie speichere ich diese Angaben möglichst effizient, und 2. wie speichere ich entsprechend die Daten die Anwender später in das so generierte Formular eintragen?
Du speicherst Schema und Daten. Da Du fuer's Schema ja nicht immer jeweils eine neue DB anlegen wirst, musst Du moeglicherweise XML-Dokumente nutzen.
Mein Problem hierbei, ich habe 10 verschiedene Eingabefeld-Typen(select, upload, text...), wovon die meisten anders-artige Daten speichern müssen, aber oft gibt es nur wenige Ausnahmen von der "normalen" Struktur.
Eine vermeintlich "normale" Struktur, die moeglicherweise irgendwie erkennbar ist, ist nicht normal.
[...]
Entsprechend kompliziert geht das ganze mit dem Auslesen bzw. Eintragen von Eingaben die im Formular getätigt wurden. Im Augenblich sehe ich eigentlich keinen besseren Weg, aber vielleicht hat ja jemand eine Idee wie man sowas besser machen kann - wenn Ihr denn versteht was ich meine ;-)
Ich verstehe selbstverstaendlich, was Du meinst. Aber vielleicht meinst Du etwas anderes?
Gruss,
Lude -
N'Abend,
mal ganz platt: Tabellen werden in SQL über SQL-Befehle erstellt, ebenso kannst Du die Tabellenstruktur bis zum letzten Fitzel mit SQL-Befehlen abfragen. Was hindert Dich daran, für jedes Formular die passende Tabelle einfach zu erzeugen?
Eine Universaltabelle halte ich jedenfalls so pauschal für herzlich wenig sinnvoll, im Gegenteil, mit dem dann nötigen Ja-wenn-dann-aber-Gewusel baust Du Dir eher noch mehr Probleme ein. Mal ganz zu schweigen davon, daß Du dann am Ende auch gleich eine Textdatei benutzen kannst.
Gruß,
soenk.e-
Hi,
mal ganz platt: Tabellen werden in SQL über SQL-Befehle erstellt, ebenso kannst Du die Tabellenstruktur bis zum letzten Fitzel mit SQL-Befehlen abfragen. Was hindert Dich daran, für jedes Formular die passende Tabelle einfach zu erzeugen?
ich vermute, dass eine Tabelle nicht ausreicht.
Eine Universaltabelle halte ich jedenfalls so pauschal für herzlich wenig sinnvoll, im Gegenteil, mit dem dann nötigen Ja-wenn-dann-aber-Gewusel baust Du Dir eher noch mehr Probleme ein. Mal ganz zu schweigen davon, daß Du dann am Ende auch gleich eine Textdatei benutzen kannst.
Eine "XML-Datei".
Gruss,
Lude-
Hi!
mal ganz platt: Tabellen werden in SQL über SQL-Befehle erstellt, ebenso kannst Du die Tabellenstruktur bis zum letzten Fitzel mit SQL-Befehlen abfragen. Was hindert Dich daran, für jedes Formular die passende Tabelle einfach zu erzeugen?
naja, eigentlich hast Du Recht. Wobei mir nicht so lieb ist wenn Anwender derart weitreichende Rechte haben. Außerdem habe ich danach 1000de Tabellen, wird dann arg unübersichtlich, außerem ist so eine Große Zahl an Tabellen schlecht für Lesezugriffe der Datenbank - soweit ich weiß.
ich vermute, dass eine Tabelle nicht ausreicht.
das ist das Problem, wobei, ich kann ja auch mehrere Tabellen erzeugen.
Eine "XML-Datei".
Ah! Also doch ein Einsatzgebiet für XML? Das würde ich auf alle Fälle selbst generierten Tabellen vorziehen. Wobei, was mache ich mit den Eingaben in das generierte Formular? Auch XML? Das sind zwar nicht so viele Datensäzte, vermutlich im Schnitt 10-100, naja, würde auf alle Fälle meine eh stark beanschpruchte DB entlasten - zumindest wenn es performanter ist.
Aber Ihr seid davon überzeugt dass ich das lieber nicht mit einem relationalen Daten-Schema abbilden sollte?
Viele Grüße
Andreas-
Hi,
ich vermute, dass eine Tabelle nicht ausreicht.
das ist das Problem, wobei, ich kann ja auch mehrere Tabellen erzeugen.Du muesstest m.E. mehrere DBs erzeugen.
Eine "XML-Datei".
Ah! Also doch ein Einsatzgebiet für XML?Ja!? ;-)
Das würde ich auf alle Fälle selbst generierten Tabellen vorziehen.
Selbstgenerierte DBs auch?
Wobei, was mache ich mit den Eingaben in das generierte Formular? Auch XML?
Schema wird durch Deinen Formulargenerator bestimmt (XSD z.B.), "Eingaben" sind XML-Dokumente, die dem Schema entsprechen.
Das sind zwar nicht so viele Datensäzte, vermutlich im Schnitt 10-100, naja, würde auf alle Fälle meine eh stark beanschpruchte DB entlasten - zumindest wenn es performanter ist.
Wenn nicht XML, dann Dein RDBMS mit x Datenbanken und y Tabellen und z Datensaetzen am Start.
Aber Ihr seid davon überzeugt dass ich das lieber nicht mit einem relationalen Daten-Schema abbilden sollte?
Einer der "Ihr" schon.
Gruss,
Lude -
mal ganz platt: Tabellen werden in SQL über SQL-Befehle erstellt, ebenso kannst Du die Tabellenstruktur bis zum letzten Fitzel mit SQL-Befehlen abfragen. Was hindert Dich daran, für jedes Formular die passende Tabelle einfach zu erzeugen?
naja, eigentlich hast Du Recht. Wobei mir nicht so lieb ist wenn Anwender derart weitreichende Rechte haben. Außerdem habe ich danach 1000de Tabellen, wird dann arg unübersichtlich, außerem ist so eine Große Zahl an Tabellen schlecht für Lesezugriffe der Datenbank - soweit ich weiß.Eine "XML-Datei".
Ah! Also doch ein Einsatzgebiet für XML?XML ist nichts weiter als eine andere Form der Datenhaltung. Der einzige Vorteil ist, daß die Daten baumweise und recht frei strukturiert werden können, das ist aber auch alles. Dies würde Dir beim Speichern der Formulare allerdings durchaus entgegen kommen.
Es macht aber keinerlei Unterschied, ob Du Deinen Benutzern erlaubst, Tabellen anzulegen, oder ihnen erlaubst, Dateien anzulegen. Darüber hinaus hat XML einen ganz extrem gravierenden Nachteil: Es verwendet das mit weitem Abstand schlechtest geeignete Format zum Speichern von Daten: einen Bytestrom. Für Dich als Benutzer mag es wunderbar strukturiert aussehen, für den Computer ist es nichts weiter als eine unendlich lange Kette von Bytes, die er Byte für Byte einlesen und interpretieren muß.
Der Grund, warum Datenbanken so schnell sind, sind die Indizes und/oder blockweise Datenhaltung - beides ist bei XML-Dateien normalerweise nicht vorhanden. Dazu kommt dann noch, daß Datenbanken sowohl ihre Verwaltungsinformationen als auch die Daten "roh" speichern können und nicht in XML-fähige Texte umsetzen müssen bzw. vom Text aus wieder in ein vom Computer verwendbares Format.XML ist deshalb in erster Linie ein (wirklich wunderbares) Daten_austausch_format und nicht zum eigentlichen Speichern von Daten gedacht. IIRC ist das auch in der Einleitung der XML-Spezifikation so beschrieben und mir ist nach wie vor schleierhaft, warum alle Welt so sehr auf XML für alles und jedes steht.
Das beste Beispiel für die Unbrauchbarkeit von XML für die Datenhaltung ist meiner Meinung nach ja dieses Forum und seine bekanntermaßen zeitweise recht gemächliche Geschwindigkeit, die -soweit mir bekannt- immer dann rapide in den Keller geht, wenn die Forumsdaten geschrieben (oder gelesen) werden müssen. Das Problem wurde dadurch eingrenzt, daß ein Speichercache dazwischen geschaltet wurde und nur selten tatsächlich gespeichert wird - mit entsprechendem Datenverlust bei Ausfällen zur Folge.Aber egal: XML ist für Deine Formulare durchaus sehr gut geeignet, die Verwaltung der über das Formular eingegebenen Daten würde ich aber wirklich "einem Profi überlassen", einer Datenbank.
Gruß,
soenk.e-
Hi!
XML ist nichts weiter als eine andere Form der Datenhaltung. Der einzige Vorteil ist, daß die Daten baumweise und recht frei strukturiert werden können, das ist aber auch alles. Dies würde Dir beim Speichern der Formulare allerdings durchaus entgegen kommen.
schon, wobei, so kompliziert wird das auch nicht relational. Und im prinzip muss ich beim auslesen eiens XML-Baums genau dasselbe machen wie mir die Daten aus den relationale Tabellen zusammensuchen, nur eben das ich das bei der DB jedemal mit einer DB-Abfrage machen muss. Auf der anderen Seite muss ich nicht immer die gesamten Daten durchgehen.
Es macht aber keinerlei Unterschied, ob Du Deinen Benutzern erlaubst, Tabellen anzulegen, oder ihnen erlaubst, Dateien anzulegen. Darüber hinaus hat XML einen ganz extrem gravierenden Nachteil: Es verwendet das mit weitem Abstand schlechtest geeignete Format zum Speichern von Daten: einen Bytestrom. Für Dich als Benutzer mag es wunderbar strukturiert aussehen, für den Computer ist es nichts weiter als eine unendlich lange Kette von Bytes, die er Byte für Byte einlesen und interpretieren muß.
Bei kleinen Datenmengen ist das ja kein problem, denn auf der anderen Seite muss due Software jedesmal eine Verbinding zur DB herstellen, und in meinem Fall könnte die Daten nicht mit einer Abfrage ermittelt werden, sondern in jedem Datensqatz muss überprüft werden um welchen Typen es sich handelt und ggfs. eine ander Tabelle abgefragt werden, ist die Frage was da jetzt effizienter istm, ich denke bei wenig Daten pro Formukar ist XML durchaus schnell, nur habe ich mir das parsen von XML etwas einfacher vorgestellt, und über das erzeugen will ich lieber noch gar nicht nachdenken ;-)
Der Grund, warum Datenbanken so schnell sind, sind die Indizes und/oder blockweise Datenhaltung - beides ist bei XML-Dateien normalerweise nicht vorhanden.
Gut das ist ja kein großes Problem selbst einen index aufzubauen, und den z.B. in einem PHP-Array fest zu speichern.
Dazu kommt dann noch, daß Datenbanken sowohl ihre Verwaltungsinformationen als auch die Daten "roh" speichern können und nicht in XML-fähige Texte umsetzen müssen bzw. vom Text aus wieder in ein vom Computer verwendbares Format.
Ja das stimmt schon. Das probelm ist nur, dass ich keien DB.Struktur finde, die ich direlkt mit ein paar Joins abfragen kann, ich muss die Datensätze immer nacheinander durchgehen, in PHP fragen fragen was für ein Feldtyp, und die entsprechende Tabelle dann weiter abfragen. Oder wäre das vielleicht eien Aufgabe die ich mit stored-procedures oder Trigger lösen könnte?
XML ist deshalb in erster Linie ein (wirklich wunderbares) Daten_austausch_format und nicht zum eigentlichen Speichern von Daten gedacht. IIRC ist das auch in der Einleitung der XML-Spezifikation so beschrieben und mir ist nach wie vor schleierhaft, warum alle Welt so sehr auf XML für alles und jedes steht.
Da hast Du eigentlich Recht.
Das beste Beispiel für die Unbrauchbarkeit von XML für die Datenhaltung ist meiner Meinung nach ja dieses Forum und seine bekanntermaßen zeitweise recht gemächliche Geschwindigkeit, die -soweit mir bekannt- immer dann rapide in den Keller geht, wenn die Forumsdaten geschrieben (oder gelesen) werden müssen. Das Problem wurde dadurch eingrenzt, daß ein Speichercache dazwischen geschaltet wurde und nur selten tatsächlich gespeichert wird - mit entsprechendem Datenverlust bei Ausfällen zur Folge.
Tja...
Aber egal: XML ist für Deine Formulare durchaus sehr gut geeignet, die Verwaltung der über das Formular eingegebenen Daten würde ich aber wirklich "einem Profi überlassen", einer Datenbank.
Ja, das könnte man so machen.
Aber womit parse ich am besten XML mit PHP? Hat da jemand von Euch Erfahrung?
Mal als Beispiel die alte XML-Struktur aus dem letzten Thread, ist ja ein ähnliches Problem:
<?xml version="1.0" encoding="ISO-8859-1"?>
<Warengruppen>
<Lebensmittel>
<Getränke>
</Getränke>
<Molkereiprodukte>
<Milchprodukte>
</Milchprodukte>
<Quarkprodukte>
</Quarkprodukte>
</Molkereiprodukte>
<Backwaren>
</Backwaren>
</Lebensmittel>
</Warengruppen>Wie würdet Ihr das parsen? Ich habe es mal mit fogenmder Funktion versucht: http://de.php.net/manual/de/function.xml-parse-into-struct.php
Aber das gibt eine recht wilde Struktur wie ich finde. Mit welchen Funktionen würdet Ihr das machen? mit den Expat(aber dann wie im Beispiel auf http://de.php.net/manual/de/ref.xml.php, oder?) oder den DOM-XML Funktionen?
Kennt da vielleicht jemand eine gute Anleitung, halt XML-parsen mit PHP? Habe das noch nie gemacht und irgendwie komme ich mit beiden Versionen(Expat/DOM) noch nicht so richtig klar, ist doch etwas komplizierter als ich immer gedacht hatte :-)Oder bringt PEAR hier irgendwas: http://pear.php.net/manual/en/package.xml.php? Aber auch dazu finde ich keine vernünftige Dokumentation. Was würdet Ihr empfehlen?
Viele Grüße
Andreas-
Hallo Andreas,
Wie würdet Ihr das parsen?
Verstehe deine Frage nicht.
Aber das gibt eine recht wilde Struktur wie ich finde.
Die Struktur gibst ja du vor. Wie kann sie denn da für dich "wild" sein?
Grüße
Thomas-
Hi!
Wie würdet Ihr das parsen?
Verstehe deine Frage nicht.
Vorab - ich habe überhaupt keine Erfahrung von XML, daher weiß ich nicht so recht wie ich das alles anstellen soll. Ich habe zwar mal die XML-Kapitel von SELFHTML gelesen, und das ganze ist auch kein Problem, nur ist der Aufbau von XML, DTDs jnd XSLT ja ganz was anderes als XML als Speicherformat oder Datenaustauschformat in eine Anwendungt zu integrieren, denn _da_ liegt mein Problem, wie ich ein bestimmtes Schema integrieren kann, das heißt parsen und erzeugen/verändern. Konkret geht es darum - wie überführe ich das XML-Schema in einen PHP-Array, den ich dann verwenden kann um das Formular die Daten aus der XML-Datei anzuzeigen, ein Formular zu erzeugen oder... Ich habe das noch nie gemacht. Was ich allerdings bisher gelesen habe, ist dass man es auf alle Fälle mit so eigenen regEx Parsern vergessen kann. Dann gibt es halt die Expat und die DOMXML Funktionen, ich denke mit den Expat-Funktionen kann ich es hinbekommen, muss halt probieren...
Und was ist mit schreiben, sagen wir ich habe die Daten in einem PHP-Array, würdet Ihr Euch für den Fall einen eigenen "writer" bauen der die Datei einfach mit fopen und fputs ("<element>")... erzeugt? Oder gibt es da auch bessere Möglichkeiten?
Aber das gibt eine recht wilde Struktur wie ich finde.
Die Struktur gibst ja du vor. Wie kann sie denn da für dich "wild" sein?
Ich meine den Aufbau des Arrays der da rauskommt, das der macht mir aus der verzweigten XML-Struktur einen linearen Array mit den Elementen, dazu einen Index-Array. Ich hätte gerne einen Array der ebenso verzweigt ist wie die XML-Struktur.
Grüße
Andreas-
Hallo Andreas,
Konkret geht es darum - wie überführe ich das XML-Schema in einen PHP-Array, den ich dann verwenden kann um das Formular die Daten aus der XML-Datei anzuzeigen, ein Formular zu erzeugen oder... Ich habe das noch nie gemacht. Was ich allerdings bisher gelesen habe, ist dass man es auf alle Fälle mit so eigenen regEx Parsern vergessen kann. Dann gibt es halt die Expat und die DOMXML Funktionen, ich denke mit den Expat-Funktionen kann ich es hinbekommen, muss halt probieren...
Du könntest PHP mit "--with-dom" kompilieren bzw. in der php.ini die extension php_domxml.dll aktivieren.
Aber ich empfehle dazu einfach das Buch von Antje zu kaufen http://www.amazon.de/exec/obidos/ASIN/3772360602/ darin findest du eine Menge über PHP und XML.Die Struktur gibst ja du vor. Wie kann sie denn da für dich "wild" sein?
Ich hätte gerne einen Array der ebenso verzweigt ist wie die XML-Struktur.Wie du das tatsächlich in eine Datei schreibst kann ich dir nicht sagen, aber DOM wäre für dich hier das richtige (wenn du eine baumartige Struktur wünschst), damit hätest du eben so eine Baumstruktur im Speicher und könntest mit den DOM XML funktionen auf diesem Baum zugreifen und die gewünschte Elemente oder Attribute etc. selektieren:
$domdoc = domxml_open_file($xmlFile);
$arr_domdocelement = $domdoc -> get_elements_by_tagname("verfasser");
print_r($arr_domdocelement);oder
$domdoc = domxml_open_file($xmlFile);
$domdocelement = $domdoc -> document_element();
print_r($domdocelement -> chld_nodes()); //Ergibt ein ArrayAber 1) ich verstehen icht viel davon und
2) Atjes Buch beschreib diese dinge wirklich sehr gut.Grüße
Thomas
-
-
-
-
Hallo,
Darüber hinaus hat XML einen ganz extrem gravierenden Nachteil: Es verwendet das mit weitem Abstand schlechtest geeignete Format zum Speichern von Daten: einen Bytestrom. Für Dich als Benutzer mag es wunderbar strukturiert aussehen, für den Computer ist es nichts weiter als eine unendlich lange Kette von Bytes, die er Byte für Byte einlesen und interpretieren muß.
Ich bin mir sicher jemand, kann mir erklären wo der Unterschied zwischen Absenden und Speichern von Daten eines Formulars als XML und dem Absenden und Speichern von Daten eines Formulars als DB-Einträge liegen soll. Es wäre mir nämlich neu, dass beim Speichern in einer DB nicht Bytes vom Rechner zu Rechner übertragen werden würden.
Was wird bei dir in einer DB gespeichert wenn nicht Bytes?
Aber wenn wir schon beim Byte-Zählen sind, Stichwort könnte Canonical XML sein.Das beste Beispiel für die Unbrauchbarkeit von XML für die Datenhaltung ist meiner Meinung nach ja dieses Forum und seine bekanntermaßen zeitweise recht gemächliche Geschwindigkeit, die -soweit mir bekannt- immer dann rapide in den Keller geht, wenn die Forumsdaten geschrieben (oder gelesen) werden müssen. Das Problem wurde dadurch eingrenzt, daß ein Speichercache dazwischen geschaltet wurde und nur selten tatsächlich gespeichert wird - mit entsprechendem Datenverlust bei Ausfällen zur Folge.
Das ist mal unter dem Strich eher das beste Beispiel für eine unüberlegte und recht unqualifizierte Aussage.
Wie du es eigentlich wissen solltest, liegen die diesbezügliche Probleme in ersten Linie in Hardware-Fragen.Warum sagst du nicht einfach dass du XML nicht leiden kannst (bzw. nicht damit umgehen kannst?)?
Grüße
Thomas-
Darüber hinaus hat XML einen ganz extrem gravierenden Nachteil: Es verwendet das mit weitem Abstand schlechtest geeignete Format zum Speichern von Daten: einen Bytestrom.
Es wäre mir nämlich neu, dass beim Speichern in einer DB nicht Bytes vom Rechner zu Rechner übertragen werden würden.
Und, habe ich behauptet, daß eine Datenbank Äpfel speichert? Oder solltest Du etwa den Unterschied zwischen Bytes, einem Bytestrom und Byteblöcken nicht kennen?
Das beste Beispiel für die Unbrauchbarkeit von XML für die Datenhaltung ist meiner Meinung nach ja dieses Forum und seine bekanntermaßen zeitweise recht gemächliche Geschwindigkeit,
Wie du es eigentlich wissen solltest, liegen die diesbezügliche Probleme in ersten Linie in Hardware-Fragen.
Da hast Du vollkommen recht. Manche Leute ziehen in eine größere Wohnung, wenn sie den Fußboden der alten vollständig mit Kartons und Tüten zugestellt haben, andere kaufen ein Regal, um ihre Sachen unterzubringen.
Warum sagst du nicht einfach dass du XML nicht leiden kannst (bzw. nicht damit umgehen kannst?)?
"Ich kann XML nicht leiden und bin zu dumm, damit umzugehen." Hat zwar nichts mit meiner (auch hier im Thread bereits kundgetanen) Meinung von XML zu tun, aber ich hoffe, damit Deine Erwartungen auf das Vortrefflichste erfüllt zu haben.
Gesegnete Nachtruhe,
soenk.e-
Hallo,
Und, habe ich behauptet, daß eine Datenbank Äpfel speichert?
Ja, so ziemlich das.
Wie du es eigentlich wissen solltest, liegen die diesbezügliche Probleme in ersten Linie in Hardware-Fragen.
Da hast Du vollkommen recht. Manche Leute ziehen in eine größere Wohnung, wenn sie den Fußboden der alten vollständig mit Kartons und Tüten zugestellt haben, andere kaufen ein Regal, um ihre Sachen unterzubringen.
Na Hauptsache ist, das man noch Äpfel von Birnen und hinkende Vergleiche von dreibeinigen Hunden unterscheiden kann.
Obwohl das Thema was das Forum betrifft (aber auch sonst) schon oft genug diskutiert wurde; begründe bitte deine Meinung bezüglich der Unbrauchbarkeit von XML für die Datenhaltung für das Forum. Bitte brücksichtige dabei, dass du Probleme die sich aus hardwaretechnischen Fragen ergeben _nicht_ berücksichtigen/heranziehen solltest.
Warum sagst du nicht einfach dass du XML nicht leiden kannst (bzw. nicht damit umgehen kannst?)?
»»"Ich kann XML nicht leiden und bin zu dumm, damit umzugehen."
Ob du zu dumm bist, muss du selber wissen.
Aber ich habe in den letzten Jahren oft genug erlebt und erlebe es noch immer wieder, dass die Ablehnung von XML einfach auf mangelnde Kentnisse bzw. Verständnis basiert. Und beide wären, wie bei allen anderen Sachen, notwendig um mit XML umgehen zu können.Hat zwar nichts mit meiner (auch hier im Thread bereits kundgetanen) Meinung von XML zu tun,
Deine einzige Aussage zu XML in diesem Thread lautete: "Das beste Beispiel für die Unbrauchbarkeit von XML für die Datenhaltung ist meiner Meinung nach ja dieses Forum".
Das ist nunmal eine unqualifizierte Aussage.
Grüße
Thomas-
Etwas grundsätzliches zum Abschluss:
Hat zwar nichts mit meiner (auch hier im Thread bereits kundgetanen) Meinung von XML zu tun,
Deine einzige Aussage zu XML in diesem Thread lautete: "Das beste Beispiel für die Unbrauchbarkeit von XML für die Datenhaltung ist meiner Meinung nach ja dieses Forum".
Ich schrieb in [pref:t=54068&m=300296], dritter Absatz, erster Satz: "XML ist deshalb in erster Linie ein (wirklich wunderbares) Daten_austausch_format [..]".
Voll des Lobes für XML zum Austauschen von Daten, geflissentlich von Dir "übersehen". Warum, möge Dein Geheimnis bleiben.
Geheiligten Sonntag,
soenk.ePS: Ok, ich gebe zu, die Erklärung für dieses "Übersehen", nicht nur im Hinblick auf das Leugnen der Existenz dieser Aussage, sondern auch auf Deine sofortige Aufforderung hin, ich möge doch gewissermaßen auf die Knie fallen und gestehen, daß ich "XML nicht leiden kann", interessiert mich tatsächlich brennend. Ich bin ja so ein selbstherrliches Diskussionsschwein ;>
-
Hallo,
Ich schrieb in [pref:t=54068&m=300296], dritter Absatz, erster Satz: "XML ist deshalb in erster Linie ein (wirklich wunderbares) Daten_austausch_format [..]".
Voll des Lobes für XML zum Austauschen von Daten, geflissentlich von Dir "übersehen". Warum, möge Dein Geheimnis bleiben.
Es ist kein Geheimniss. Du hast ja auch noch dazugeschrieben:
"[...] und nicht zum eigentlichen Speichern von Daten gedacht. IIRC ist das auch in der Einleitung der XML-Spezifikation so beschrieben"Da es in der Spezifikation keinerlei derartige Beschreibung existiert, ist diese Aussage von dir ebenfalls obsolet. Warum sollte ich das dann noch extra erwähnen?
"Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere."
Zu lesen auf der Hauptseite der W3C XML-Seiten.
Dass XML für den Datenaustausch gut geignet ist, wurde auch von mir nicht bezweifelt, aber ich habe mich schon zu genüge darüber geäußert, dass die Reduktion von XML auf die bloße Möglichkeit des Datenaustausches ein eklatanter Fehler ist, der nur auf eine ungenügenden Beschäftigung mit der Materie bzw. auf mangelnde Verstädnis der selben zurückzuführen sei.PS: Ok, ich gebe zu, die Erklärung für dieses "Übersehen", nicht nur im Hinblick auf das Leugnen der Existenz dieser Aussage, sondern auch auf Deine sofortige Aufforderung hin, ich möge doch gewissermaßen auf die Knie fallen und gestehen, daß ich "XML nicht leiden kann", interessiert mich tatsächlich brennend.
Dass du XML nicht leiden kannst, implizieren deine Postings in diesem Thread.
Grüße
Thomas-
Ich schrieb in [pref:t=54068&m=300296], dritter Absatz, erster Satz: "XML ist deshalb in erster Linie ein (wirklich wunderbares) Daten_austausch_format [..]".
Voll des Lobes für XML zum Austauschen von Daten, geflissentlich von Dir "übersehen".
Du hast ja auch noch dazugeschrieben:
"[...] und nicht zum eigentlichen Speichern von Daten gedacht. IIRC ist das auch in der Einleitung der XML-Spezifikation so beschrieben"Da es in der Spezifikation keinerlei derartige Beschreibung existiert, ist diese Aussage von dir ebenfalls obsolet.
Hurra! Du erklärst also mein ausdrückliches Lob (und es bleibt ein Lob, unabhängig vom Rest des Absatzes) kurzerhand für überflüssig bzw. nicht existent, damit Du nicht mit meiner angeblich "einzigen" Aussage und der darauf basierenden Unterstellung, ich sei XML-Hasser, auf die Nase fällst.
Auf dieser Grundlage erübrigt sich jegliche Erörterung sachlicher Themen. Ich bin vielleicht nicht der Super-Duper-XML-Crack, wie Du es bist, die Person mit den Scheuklappen sitzt in jedem Fall definitiv nicht an diesem Ende der Leitung.
Aber es hat mich gefreut, daß Du mit Deinem dümmlichen Vorwurf so schön die Hosen runtergelassen hast :>Gruß,
soenk.e-
Hallo,
Hurra! Du erklärst also mein ausdrückliches Lob (und es bleibt ein Lob, unabhängig vom Rest des Absatzes) kurzerhand für überflüssig bzw. nicht existent, damit Du nicht mit meiner angeblich "einzigen" Aussage und der darauf basierenden Unterstellung, ich sei XML-Hasser, auf die Nase fällst.
- XML ist nach wie vor kein Datenaustauschformat in erster Linie.
1a) dass XML sich als Datenaustauschformat gut eignet, habe ich, wie gesagt, auch nicht beweifelt. - Dieser Halbsatz von dir im Bezug auf das Ganze als solches, ändert leider nichts an der Fehlerhaftigkeit deiner Aussage.
Auf dieser Grundlage erübrigt sich jegliche Erörterung sachlicher Themen.
Du wirfst mir unsachlichkeit vor, aber gehst selbst auf keinerlei sachliche Frage ein: "begründe bitte deine Meinung bezüglich der Unbrauchbarkeit von XML für die Datenhaltung (für das Forum)".
Aber es hat mich gefreut, daß Du mit Deinem dümmlichen Vorwurf so schön die Hosen runtergelassen hast :>
Wie du meinst.
Grüße
Thomas-
Hallo Jungs!
Entspannt Euch! Ist irgendwie ziemlich sinnlos sich wegen sowas zu beschimpfen. Ist nunmal so dass die Leute hier verschiedene Vorlieben und verschiedene Wissenstände haben, was ja durchaus zusammenhängen kann. Aber gerade das ist ja das schöne hier, es gibt eigentlich zu jedem Themenbereich fast immer jemanden der sich besser auskennt. Ich habe wie man hier sehr schön sieht überhaupt keine Ahnung von XML, und das würde ich gerne ändern, daher die Fragen.
Warum die Forums-Nachrichten in XML gespeichert werden verstehe ich ehrlich gesagt auch nicht wirklich, da stimme ich mit Sönke überein. Auf der anderen Seite bin ich mir aber auch sicher, dass CK die Speicherung in einer DB bewußt vermieden hat - warum auch immer, es wird triftige Gründe geben, denn PostgreSQL wird ja eingesetzt und wäre auch verfügbar gewesen.Naja, vielleicht sind ja auch die tropischen Temperaturen schuld an so manchen hitzigen Auseinandersetzungen ;-)
Viele Grüße
Andreas-
Hallo Andreas,
Entspannt Euch!
Also ich fand das ganze ziemlich amüsant. ;-)
Warum die Forums-Nachrichten in XML gespeichert werden verstehe ich ehrlich gesagt auch nicht wirklich, da stimme ich mit Sönke überein. Auf der anderen Seite bin ich mir aber auch sicher, dass CK die Speicherung in einer DB bewußt vermieden hat - warum auch immer, es wird triftige Gründe geben, denn PostgreSQL wird ja eingesetzt und wäre auch verfügbar gewesen.
Damals war kein PostgreSQL verfügbar und sie wird auch heute noch nicht eingesetzt. (Aber bald).
Die Entscheidung für XML war mals mehr oder weniger Experimentierlust, aber ich finde die Datenhaltung der Threads in XML sehr gut.
Ich sehe was für verrenkungen ich machen muss bei Foren, wo die Daten einzelene Postings als flache Struktur (als XML) aus der DB kommen und nur durch irgendwelche obskure ID-Querverweise miteinander verknüpft sind, bis daraus wieder etwas wird was einem Forum ähnelt und nicht nur ein flaches Board ist.
Dagegen sind unsere XML-Dateien hier im Forum ein echtes Vergnügen mit ihren hierarchischen Datenstruktur.Zweitens, wie gesagt, wir hatten damals keine DB und es war wichtig, dass wir für die Datenhaltung ein Format einsetzen, das wir problemlos nicht nur in andere Formate umwandeln, aber auch transportieren können. Dazu kam der Wunsch der Trennung von Layout und Inhalt. XML erfüllte und erfüllt noch heute all diese Kriterien.
Grüße
Thomas-
HI Thomas!
Damals war kein PostgreSQL verfügbar und sie wird auch heute noch nicht eingesetzt.
Doch, nur nicht für die Nachrichten, sondern für die HTTP-Auth Daten.
(Aber bald).
??? Meinst Du für die Suche? Das heißt dann beim Schreiben der Daten wird in die DB geschrieben und nicht in eine XML-Datei? Heißt das zur Zeit wird die XML-Variante nur aufrecht erhalten aus Gründen der Kompatibilität zur alten suche, wobei die doch glaube ich speziell präparierte Dateien durchsucht, oder?
Die Entscheidung für XML war mals mehr oder weniger Experimentierlust, aber ich finde die Datenhaltung der Threads in XML sehr gut.
Ja, aber das Forum ist doch komplett neu geschrieben worden, weiso wird dann das alte Format beibehalten?
Dagegen sind unsere XML-Dateien hier im Forum ein echtes Vergnügen mit ihren hierarchischen Datenstruktur.
Klar, aber bei der Menge Daten frage ich mich wirklich ob da eine DB nicht effelktiver wäre, trotz Parent_ID - Konstrukten...
Zweitens, wie gesagt, wir hatten damals keine DB und es war wichtig, dass wir für die Datenhaltung ein Format einsetzen, das wir problemlos nicht nur in andere Formate umwandeln, aber auch transportieren können. Dazu kam der Wunsch der Trennung von Layout und Inhalt. XML erfüllte und erfüllt noch heute all diese Kriterien.
Viele Grüße
Andreas-
PS: jetzt hatte ich ja fast die Frage die mir schon so lange auf den Lippen liegt vergessen: Wieso wird das Archiv dynamisch ausgegeben und nicht ainfach statisch? Oder irre ich mich da jetzt?
Grüße
Andreas-
Hi Andreas,
PS: jetzt hatte ich ja fast die Frage die mir schon so lange auf den Lippen liegt vergessen: Wieso wird das Archiv dynamisch ausgegeben und nicht ainfach statisch?
für die Speicherung der Daten existieren andere Anforderungen als für die Visualisierung der Daten in einem Web-Browser. Könnten alle gängigen Web-Browser XML problemlos direkt anzeigen, dann wäre Deine Frage sehr viel berechtigter.
Da sie es anscheinend nicht können, lauten die Alternativen, entweder dynamisch zwischen der internen und der externen Darstellung zu konvertieren oder zwei Instanzen statisch vorzuhalten (also quasi einen Cache zu verwenden) und dafür aber sämtliche Eingriffe simultan in beiden Strukturen durchführen zu müssen (oder beide Datenbestände versehentlich auseinander laufen zu lassen, was noch schlimmer wäre).Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi Michael!
für die Speicherung der Daten existieren andere Anforderungen als für die Visualisierung der Daten in einem Web-Browser. Könnten alle gängigen Web-Browser XML problemlos direkt anzeigen, dann wäre Deine Frage sehr viel berechtigter.
Trotzdem finde ich gerade bei der Speicherung weniger die Porttierbarkeit wichtig, sondern eher das schnelle schreib und Lesezugriffe möglich sind. Es sollte kein problem sein eine Export-Funktion zu implementieren die die Daten aus eienr relationalen Datenbank in XML übersetzt. Aber vielleicht geht das parsen von XML ja am schnellsten, wie gesagt fehlt mir da die Erfahrung.
Da sie es anscheinend nicht können, lauten die Alternativen, entweder dynamisch zwischen der internen und der externen Darstellung zu konvertieren oder zwei Instanzen statisch vorzuhalten (also quasi einen Cache zu verwenden) und dafür aber sämtliche Eingriffe simultan in beiden Strukturen durchführen zu müssen (oder beide Datenbestände versehentlich auseinander laufen zu lassen, was noch schlimmer wäre).
Es gäbe ja auch noch die Möglichkeit die Daten per Apache Modul(weiß nicht so genau welches) per XSLT zu transformieren, naja, aber da hat sich CK sicher mehr mit beschäftigt als ich.
Aber wieviel wird denn hier pro Tag geschrieben? ca. 500 KB? 500 KB an eine Datei anzufügen, und das ganze noch zu komprimieren, wäre das denn so ein Aufwand? Im Gegensatz zum - keine Ahnung - vielleicht 10 fachen Aufwand zur Laufzeit durch PERL? Das war mein Gedanke, und ich kann mir denken dass das schon seinen Grund hat, nur so 100%ig bin ich noch nicht da hintergestiegen ;-)Grüße
Andreas-
Hi Andreas,
Es sollte kein problem sein eine Export-Funktion zu implementieren die die Daten aus eienr relationalen Datenbank in XML übersetzt.
für Postings, okay. Für Threads, doch - das ist ein Problem. (Siehe Archiv.)
Aber vielleicht geht das parsen von XML ja am schnellsten, wie gesagt fehlt mir da die Erfahrung.
Das schnellste Parsen ist dasjenige, was überhaupt nicht (bzw. nur einmal beim daemon-Start) gemacht werden muß.
Es gäbe ja auch noch die Möglichkeit die Daten per Apache Modul(weiß nicht so genau welches) per XSLT zu transformieren, naja, aber da hat sich CK sicher mehr mit beschäftigt als ich.
Das ist eine Frage der technischen Umsetzung, nicht des Prinzips. (Und Christian scheint lieber selbst coden als ein Fremdprodukt verwenden zu wollen, was ich ihm bei einer derartig offensichtlich auf Tuning ausgelegten Implementierung nicht verdenken kann: Wenn einer seiner Bausteine zu langsam ist, dann hat er wenigstens die volle Handlungsfreiheit, ihn zu verbessern bzw. ersetzen.
Aber wieviel wird denn hier pro Tag geschrieben? ca. 500 KB? 500 KB an eine Datei anzufügen, und das ganze noch zu komprimieren, wäre das denn so ein Aufwand? Im Gegensatz zum - keine Ahnung - vielleicht 10 fachen Aufwand zur Laufzeit durch PERL?
Wie hoch sind die Zugriffszahlen auf das Archiv? Spielt die Visualisierung von Archiv-Postings im Vergleich zu anderen Zugriffen auf diesen Server (SelfHTML, Forums-"Cache") überhaupt eine Rolle? Faktor 10 von sehr wenig wäre immer noch nicht arg viel ... man muß nicht alles optimieren, solange man beispielsweise auch die "böse" Uni einfach aussperren kann, wenn sie DoS-artige Abfragen generiert.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi!
für Postings, okay. Für Threads, doch - das ist ein Problem. (Siehe Archiv.)
Hm, habe ich noch nicht gemacht, aber ich weiß nur, dass man das Forum so wie es ist auch in einer relationalen DB halten kann, wie Henryk Pkötz in seinem Artikel beschreibt, da wird aus der DB dann die Thread-Struktur in HTML übersetzt, XML sollte da auch nicht viel schwerer sein, aber gut, Du kennst den Artikel also sollte ich mal im Archiv recherchieren.(nicht falsch verstehen, das ist nur grundsätzlich auf die Transformation bezogen, ich meine nicht das aktuelle Forum in der DB zu halten, und diese Transformation kann so langsam sein wie sie will).
Das schnellste Parsen ist dasjenige, was überhaupt nicht (bzw. nur einmal beim daemon-Start) gemacht werden muß.
Klar!
Das ist eine Frage der technischen Umsetzung, nicht des Prinzips. (Und Christian scheint lieber selbst coden als ein Fremdprodukt verwenden zu wollen, was ich ihm bei einer derartig offensichtlich auf Tuning ausgelegten Implementierung nicht verdenken kann: Wenn einer seiner Bausteine zu langsam ist, dann hat er wenigstens die volle Handlungsfreiheit, ihn zu verbessern bzw. ersetzen.
Ja, das ist wohl so, bin ehrlich gesagt mal wieder etwas überrascht wie komplex das Forum doch ist!
Wie hoch sind die Zugriffszahlen auf das Archiv? Spielt die Visualisierung von Archiv-Postings im Vergleich zu anderen Zugriffen auf diesen Server (SelfHTML, Forums-"Cache") überhaupt eine Rolle?
Ja, normalerweise würde ich dem zustimmen, da habe ich mir auch nie Gedanken zu gemacht, nur habe ich mir sagen lassen das eben dieses Script auch Ziel von DOS-Atacken war, anscheinend gibt es da jetzt auch so einen Schutz wie bei der Suche.
Faktor 10 von sehr wenig wäre immer noch nicht arg viel ... man muß nicht alles optimieren, solange man beispielsweise auch die "böse" Uni einfach aussperren kann, wenn sie DoS-artige Abfragen generiert.
ja, wenn es denn gemacht wird bzw. zeitig erkannt wird...
Viele Grüße
Andreas
-
-
-
-
-
Hi Andreas,
Die Entscheidung für XML war mals mehr oder weniger Experimentierlust, aber ich finde die Datenhaltung der Threads in XML sehr gut.
Ja, aber das Forum ist doch komplett neu geschrieben worden, weiso wird dann das alte Format beibehalten?weil das Format bereits gut und richtig war - nur das Zugriffsverfahren (ständig einen langsamen XML-Parser aufzurufen) war verbesserungsfähig.
Dagegen sind unsere XML-Dateien hier im Forum ein echtes Vergnügen mit ihren hierarchischen Datenstruktur.
Klar, aber bei der Menge Daten frage ich mich wirklich ob da eine DB nicht effelktiver wäre, trotz Parent_ID - Konstrukten...Das, was Christian jetzt tut, ist _viel_ effizienter als eine (relationale) Datenbank (die nämlich genau das tun müßte, was Thomas beschrieben hat: Sie müßte jeden Thread durch beliebig _viele_ SQL-Statements erst mal mühsam aus den diversen Tabellen zusammensuchen, statt ihn in einer bereits fertig verknüpften Struktur permanent im Hauptspeicher zu halten).
Inwiefern eine auf XML-Anforderungen spezialisierte Datenbank das sehr viel schneller könnte als eine relationale, dazu müßte sich ggf. wieder Thomas äußern.
Aber "kein Plattenzugriff" ist nun mal deutlich schneller als "ein gut getuneter" (der ggf. einen kompletten thread extrahieren könnte), und ungeheuer viel schneller als "sehr viele gut getunete" ...Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.-
Hi!
weil das Format bereits gut und richtig war - nur das Zugriffsverfahren (ständig einen langsamen XML-Parser aufzurufen) war verbesserungsfähig.
Ich meien nicht den Zugriff auf aktuelle Forums-Daten, sondern ich meine die Archivierung, das schreiben auf die Platte.
Das, was Christian jetzt tut, ist _viel_ effizienter als eine (relationale) Datenbank
Das ist mir vollkommen klar! Abver darum ging es mir nicht, sondern darum dass das schreiben von XML-Daten auf die Platte eine größere Belastung ist als das schreiben in eine relationale Datenbank(ohne indices).
Grüße
Andreas-
Hi Andreas,
Das, was Christian jetzt tut, ist _viel_ effizienter als eine (relationale) Datenbank
Das ist mir vollkommen klar! Abver darum ging es mir nicht, sondern darum dass das schreiben von XML-Daten auf die Platte eine größere Belastung ist als das schreiben in eine relationale Datenbank(ohne indices).das würde ich so auch nicht stehen lassen wollen (abgesehen davon, daß Du beim Schreiben in die relationale Datenbank eben _genau_ die Indizes pflegen mußt, und das kostet eben auch etwas).
Die Frage ist eher, wie intelligent dieser Checkpoint-Algorithmus ist, d. h. ob er "keep it simple, dude" einfach alles raushaut oder beispielsweise pro Thread ein "last modified"-Tag hat und deshalb inkrementell sichern kann.
Viele Grüße
Michael--
T'Pol: I apologize if I acted inappropriately.
V'Lar: Not at all. In fact, your bluntness made me reconsider some of my positions. Much as it has now.
(sh:| fo:} ch:] rl:( br:^ n4:( ie:% mo:) va:| de:/ zu:| fl:( ss:) ls:~ js:|)
=> http://www.peter.in-berlin.de/projekte/selfcode/?code=sh%3A|+fo%3A}+ch%3A]+rl%3A(+br%3A^+n4%3A(+ie%3A%25+mo%3A)+va%3A|+de%3A%2F+zu%3A|+fl%3A(+ss%3A)+ls%3A~+js%3A|
Auch diese Signatur wird an korrekt konfigurierte Browser gzip-komprimiert übertragen.
-
-
-
Hallo Andreas,
(Aber bald).
??? Meinst Du für die Suche?Ja für die Suche.
Das heißt dann beim Schreiben der Daten wird in die DB geschrieben und nicht in eine XML-Datei?
Nein, die wird nur für die Indexierung verwendet.
Dani hat mal sogar ihre Arbeit unter Selfaktuell verlink, aber natürlich finde ich jetzt das nicht.Heißt das zur Zeit wird die XML-Variante nur aufrecht erhalten aus Gründen der Kompatibilität zur alten suche,
Nein, die Datenhaltung bleibt in XML.
wobei die doch glaube ich speziell präparierte Dateien durchsucht, oder?
Ja.
Ja, aber das Forum ist doch komplett neu geschrieben worden, weiso wird dann das alte Format beibehalten?
Weil das Format das richtige ist? 8-)
Klar, aber bei der Menge Daten frage ich mich wirklich ob da eine DB nicht effelktiver wäre, trotz Parent_ID - Konstrukten...
In wie fern effektiever?
Zu den anderen Postings mit Michael:
Bei einer XML-DB könnten wir die Daten nachwie vor in XML halten, die Indizes müssen aber auch dort gesetzt werden, wobei diese zumeist XPath- oder eventuell XQuery-Ausdrücke sind und die DB diese dann selbstständig "pflegt" (wenn neue dateien etc. hinzukommen).
Incrementelle Updates der XML-Dateien wären dort "nur" eine Frage der Programmierung und die Ausgabe der Daten würde per XSL-Transformation passieren, was wir ja im Moment nicht haben.
DEr Vorteil wäre dabei, dass dort eben alles zusammen ist, was zusammen gehört und müsste nicht erst per SQL-Abfragen zusammengesetzt werden, was schon eine Menge Zeit sprachen würde.
Aber die XML-DBs sind unerschwinglich teuer, bzw. ich kenne keine Opencource XML-DB (was selbstverständlich nicht bedeutet, dass es keine gibt!)Archiv als XML: darüber haben wir auch mal ausführlicher diksutiert, du kannst es ja nachlasen ;-)
»»"Trotzdem finde ich gerade bei der Speicherung weniger die Porttierbarkeit wichtig, sondern eher das schnelle schreib und Lesezugriffe möglich sind."
Das finde ich nicht, ich bin auch bereit etwas an geschwidigkeit zu opern, wenn ich dafür ein Format habe, die ich überall verwenden kann. Auch für den Problemfall finde ich XML besser, denn wenn eine der XML-Dateie beschädigt wird, kann man sie locker reparieren, bei der DB wäre das um einiges schwieriger.
XSLT-Transformation: selbe Diskussion wie beim Archiv ;-)
Grüße
Thomas-
Moin Thomas,
Aber die XML-DBs sind unerschwinglich teuer, bzw. ich kenne keine Opencource XML-DB (was selbstverständlich nicht bedeutet, dass es keine gibt!)
Es gibt eine vom Apache Projekt, die recht gut sein soll (nach ix tests):http://xml.apache.org/xindice/ Selber gearbeitet habe ich damit allerdings noch nicht. Ausserdem wird gerade an einem neuem internen Design gearbeitet, so dass sie effektiver funktionieren wird, so die Aussage in der IX.
Grüße Andres Freund
-
Hallo Andreas,
Aber die XML-DBs sind unerschwinglich teuer, bzw. ich kenne keine Opencource XML-DB (was selbstverständlich nicht bedeutet, dass es keine gibt!)
Es gibt eine vom Apache Projekt, die recht gut sein soll (nach ix tests):http://xml.apache.org/xindice/ Selber gearbeitet habe ich damit allerdings noch nicht.Wäre ja auch ein Wunder gewesen, denn es ist ja voll in Entwicklung ;-)
Das "Problem" damit, dass sie - wie viele anderen dinge auf diesem Gebiet - in Java geschrieben ist. Wenn wir hier am Server Java hätten und die Entwickler dazu, würde es hier vermutlich anderes aussehen.
Außerdem wenn die DB schon bei paar MB großen Daten den Handtuch schmeisst (siehe deren FAQ) ist es schon leider ungeiegnet für uns. Die Monats-Indexdateien im Archiv (bis jetzt so um die 5MB und sie werden größer) würden die Fähigkeiten der DB sprechengen.Trotzdem, danke für den Tip ;-)
Grüße
Thomas-
Moin,
Wäre ja auch ein Wunder gewesen, denn es ist ja voll in Entwicklung ;-)
Och, es hat doch schon die Version 1.0 erreicht ;-)
Das "Problem" damit, dass sie - wie viele anderen dinge auf diesem Gebiet - in Java geschrieben ist. Wenn wir hier am Server Java hätten und die Entwickler dazu, würde es hier vermutlich anderes aussehen.
Hm, Java sollte machbar sein. Die Datenbank könnte man auch über odcb ansprechen, was möglich sein dürfte.
Außerdem wenn die DB schon bei paar MB großen Daten den Handtuch schmeisst (siehe deren FAQ) ist es schon leider ungeiegnet für uns. Die Monats-Indexdateien im Archiv (bis jetzt so um die 5MB und sie werden größer) würden die Fähigkeiten der DB sprechengen.
Ich wollte auch nicht darauf hinaus, dass man xindice hier einsetzt. Dazu ist es imho noch viel zu unstabil und vorallem zu langsam. Ich wollte eigentlich nur zeigen, dass es sowas auch als open-source gibt ;-).
Man könnte nat. auch oracle oder ähnliches nutzen ;-).Trotzdem, danke für den Tip ;-)
Es gibt noch eine, die angeblich einigermaßen ausgereift sein soll (ähnlich wie xindice ;-)):http://exist.sourceforge.net/.
Es soll schneller und effektiver sein, allerdings noch nicht so viele Features unterstützen, und nicht so standardkonform sein. Es hätte sogar eine Anbindung zu Perl ;-). Aber ich denke auch hier, dass es nicht für die Belastung hier geignet ist.Grüße Andres Freund
Ps: Ich heiße übrigens Andres ;-)
--
ss:) zu:) ls:} fo:) de:] va:) ch:| n4:& rl:° br:^ js:( ie:% fl:( mo:|
-
-
-
-
-
-
- XML ist nach wie vor kein Datenaustauschformat in erster Linie.
-
-
-
-
-
-
-
-
-
-