Hello,
Naja, der Thread ist ein wenig zu anstrengend um den komplett zu lesen ;-)
Er ist ja auch als Vorstufe für einen etwas länglicheren Feature-Artikel gedacht. Er dokumentiert schon ganz schön die Geschichte von der ersten oberflächlichen Anforderung zur überlegten Umsetzung und zeigt auch Alternativen auf.
Ich verstehe das Problem nicht wirklich.
Ich denke, doch, denn das Problem liegt nicht in der fachlich ausgeklügelten Umsetzung (dieses RAD haben andere schon erfunden), sondern in der passenenden Skalierung der Möglichkeiten für ein Projekt und im schrittweisen Dazulernen.
IMHO solltet Ihr Euch nicht zu viele Gedanken über die Extreme machen. Bedenkt mal das Verhältnis von lesenden Anfragen zu schreibenden Anfragen. Hier im Forum sieht das im Augenblick so aus: auf 800 Aufrufe des Posting-Scriptes, kommen 24.000 lesende Zugriffe, das heißt schreibende Zugriffe machen gerade mal 3% aus.
Das ist schon einen Gedanken wert. Die Datenmengen sind also entscheidend, oder genauer gesagt, die Anzahl der Datensätze. Und da ist mein zweiter Vorschlag schon besser geeignet, das zu handhaben, allerdings auf Kosten des vergeudeten Speicherplatzes.
Bei großen Datenmengen wird das lesen von großen Flatfiles sehr langsam. Die Zahlen kommen mir zwar etwas wenig vor, aber es zeigt das Verhältnis. Das Problem ist die Optimierung für Lesezugriffe, in Anbetracht der Tatsache dass sich die Daten durch schreibende Zugriffe änderen, bzw. erweitern.
An der Ermittlung der Grenzwerte arbeiten wir. Da kann jeder einen Beitrag leisten, der uns Rückmeldung gibt.
Wie man sowas optimiert hat CK ja mit seinem Forum eindrucksvoll gezeigt. Aber dazu ist eine Menge Arbeit und Wissen notwendig. Wenn ich sowas machen müsste, dann würde ich die Probleme vorhandener Software wie Datenbank-Servern, Object-Cache-Servern... überlassen, sicher kann ein RDBMS viel was man nicht braucht - das heißt es gibt Optimierungs-Möglichkeiten, aber ich bezweifele ob man die mit PHP überhaupt entsprechend ausnutzen kann, Speichern in serialisierten Arrays ist sicher nicht optimal hierfür. Und für kleinere Anwendungen sehe ich keine Probleme ;-)
Vielleicht rede ich jetzt auch am Thema vorbei, aber dann klärt mich mal auf wo jetzt genau die Probleme liegt ;-)
Du hast keinesfalls am Thema vorbei geredet, sondern einen wertvollen Beitrag geleistet, um anderen später die Entscheidung für die passende Mehtode leichter zu machen. Eine SQL-Datenbank ist nicht immer die passende Lösung. Manchmal ist sie total überskaliert und manchmal muss sie auch speziellen Erfordernissen genügen --> Arbeitsagentur.de (um das Frontend haben die sich ja bekanntermaßen nicht gekümmert, aber die Datenbank würde mit MySQL schlapp machen *g*)
Liebe Grüße aus http://www.braunschweig.de
Tom
Fortschritt entsteht nur durch die Auseinandersetzung der Kreativen
Nur selber lernen macht schlau