Nachteil: Flatfile
0 
Felix Riesterer
0 0 dedlfix
0
0
0 0 0 0 0 0 0 Vorteil: Flatfile
Nachteil: Flatfile
Hi
ich bin gerade dabei ein kleinen Blog zu schreiben. Um dort komentare abzugeben oder sie zu lesen müssen sich user anmelden das ist kein problem. Da es sicher (und so soll es auch sein) nicht mehr als 50 user werden dachte ich mir ich nehme mir eine flatfile als datenbank. In die flatfile sollen je 4 informationen eines user gespeichert werden
1. username 2. password 3. vorname 4. email (verschlüsselt) das ist auch kein Problem. Warum ich nicht mit einer mysql datenbank arbeite? Ich habe keine zur verfügung und möchte mir auch keine holen da ich eine flatfile möchte.
Ich rede bereits zu viel :D
Was ich eigentlich fragen möchte...
Welche nachteile hat eine flatfile?
Angenommen ich schreibe etwas wo ca. 5.000 oder mehr leute sich anmelden können kann sehr schnell etwas durcheinander kommen!
Was ich bisher (ausversehen oder mit absicht) beobachtet habe:
1. wenn man für jeden user nicht jeweils eine zeile benutzt gerät alles durcheinander so sieht man zum beispiel bei nummer 4 meines beispieles (email) alle informationen des nächsten user und er ist auch nicht mehr zu erkennen da der user ja eigentlich die email des vorherigen ist
2. wenn beispielsweise vorname leer bleibt verrutscht die email auf platz 3 also bräuchte man einen platzhalter für nummer 3
3. im schlimmsten fall können fremde leute die flatfile in ihrem browser aufrufen und sie anzeigen lassen
mehr fällt mir gerade nicht ein. Natürlich kann man mit einigen abfragen und sicherheitsvorkehrungen die punkte 1-3 sichern. Aber ich kann mir nicht vorstellen dass es bei mehr als 5.000 usern noch efizient ist oder doch?
Wer hat damit schon erfahrungen gemacht? Wer weiss noch mehr nachteile einer Flatfile?
-
Lieber TetraPag,
Welche nachteile hat eine flatfile?
Performance. Je nach Anforderungen kann bei größeren Datenmengen die Performance mit einer "echten" Datenbank nicht mehr mithalten (denke an z.B. 1000 Einträge, die Du mit PHP abarbeiten musst, um an Deinen Eintrag zu gelangen).
Liebe Grüße,
Felix Riesterer.
--
ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)-
Guten Tag,
Nachteile?
Performance. Je nach Anforderungen kann bei größeren Datenmengen die Performance mit einer "echten" Datenbank nicht mehr mithalten (denke an z.B. 1000 Einträge, die Du mit PHP abarbeiten musst, um an Deinen Eintrag zu gelangen).
Das hängt aber auch stark vom Aufbau der Dateien und der Logik des Systems ab.
Man kann bei geeigenter Strategie auch mit Flatfiles und PHP eine hohe Performance erreichen. Wichtig ist dabei nur, dass mana) immer genügend Luft beim Hauptspeicher hat
b) nicht mit PHP über die Dateien iterieren muss, sondern besser
entweder direktgestreute Dateien benutzt oder eine hierarchische
Struktur für das Finden der Daten,
c) also immer variante Datenpakete und Indices voneinander getrennt hältUm den Umgang mit Daten zu lernen ist eine Lösung mit Flatfiles garantiert wirksamer. Dass das anstrengender ist, als ein fertiges DBMS zu benutzen, steht allerdings außer Frage.
Gesundheit!
Dr. Bit-
echo $begrüßung;
Man kann bei geeigenter Strategie auch mit Flatfiles und PHP eine hohe Performance erreichen. Wichtig ist dabei nur, dass man
Die schönste Performance nützt aber nichts, wenn einem die Daten flöten gehen, weil man in einer Multiuser-Umgebung keine geeignete Vorsorge getroffen hat, deshalb ein Lesetipp: Sperren von Dateien.
echo "$verabschiedung $name";
-
Hello,
Die schönste Performance nützt aber nichts, wenn einem die Daten flöten gehen, weil man in einer Multiuser-Umgebung keine geeignete Vorsorge getroffen hat, deshalb ein Lesetipp: Sperren von Dateien.
Naja, im Mometn hat PHP auch noch auf vielen Systemen Probleme mit dem Locking. LOCK_NB funktioniert nicht, es wird immer blockierend locked, egal was man beauftragt hat. Da kann es dann schon mal zu hässlichen Deadlocks kommen, wenn sich die Prozesse auf den Nonblocking-Mode verlassen haben.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hi,
Naja, im Mometn hat PHP auch noch auf vielen Systemen Probleme mit dem Locking. LOCK_NB funktioniert nicht, es wird immer blockierend locked, egal was man beauftragt hat.
Nach einiger Erfahrung mit Flatfiles sehe ich hier auch das grösste Problem, da ist der Einsatz einer DB komfortabler. Flatfiles setze ich lieber für irgendwelche Tools ein, die nur von einer überschaubaren Zahl von Nutzern angewendet wird.
Gruesse, Joachim
--
Am Ende wird alles gut. -
Hallo Tom,
Naja, im Mometn hat PHP auch noch auf vielen Systemen Probleme mit dem Locking. LOCK_NB funktioniert nicht, es wird immer blockierend locked, egal was man beauftragt hat. Da kann es dann schon mal zu hässlichen Deadlocks kommen, wenn sich die Prozesse auf den Nonblocking-Mode verlassen haben.
Das hatten wir doch letztlich erst... Es gab mal einen Bug mit LOCK_NB, der aber in aktuellen PHP-Versionen nicht mehr auftritt.
Außerdem: LOCK_NB braucht man in meinen Augen sowieso nur, wenn man ganz komplizierte Locking-Schemen hat. Und gerade bei Locking ist es oft besser, wenn man das ganze möglichst einfach hält - das spart eine Menge Ärger.
Viele Grüße,
Christian-
Hello,
Das hatten wir doch letztlich erst... Es gab mal einen Bug mit LOCK_NB, der aber in aktuellen PHP-Versionen nicht mehr auftritt.
Das stimmt.
In vielen auf Debian 4.0 mit apt-get isntallierten Systemen ist der Fehler aber noch vorhanden. Debaian hat die Pakete für PHP5 noch nicht ausgetauscht (wenn es nicht zufällig die letzten paar Tage passiert ist).Ich höre mir dauernd den Kummer von Leuten an, deren Scripte nicht mehr (oder eben noch nicht wieder) laufen.
Außerdem: LOCK_NB braucht man in meinen Augen sowieso nur, wenn man ganz komplizierte Locking-Schemen hat. Und gerade bei Locking ist es oft besser, wenn man das ganze möglichst einfach hält - das spart eine Menge Ärger.
LOCK_NB braucht man immer dann, wenn man Deadlocks vermeiden muss.
Dann ist nämlich LOCK_NB die einfachere Variante. Mit einem Wait-Lock kann man das Unheil meistens nicht vermeiden.Und gerade das ist der Kummer von den Leuten. Die haben in ihren Spielen oder was auch immer sie da zusammengebaut haben, Wettbewerb zwischen mehreren Prozessen, die sich gegenseitig die Dateien blockieren. Und dann stehen beide Scripte und warten auf ihr Timout, was dann wieder zu weiteren Folgefehlern führt, da dann meistens nur die halbe Operation fertigstellt wurde und die Daten inkonsistent werden.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
Hallo Tom,
Ich höre mir dauernd den Kummer von Leuten an, deren Scripte nicht mehr (oder eben noch nicht wieder) laufen.
Huh? Ich habe File-Locking in PHP-Anwendungen in freier Wildbahn nur sehr, sehr selten gesehen. Nichtblockierende Locks noch weniger. Insofern kann ich diese Beobachtung absolut nicht nachvollziehen.
Kann natürlich immer sein, dass es Einzelfälle gibt. Aber "dauernd" kommt mir dann doch arg übertrieben vor.
Außerdem: LOCK_NB braucht man in meinen Augen sowieso nur, wenn man ganz komplizierte Locking-Schemen hat. Und gerade bei Locking ist es oft besser, wenn man das ganze möglichst einfach hält - das spart eine Menge Ärger.
LOCK_NB braucht man immer dann, wenn man Deadlocks vermeiden muss.
Nein. Wenn man sein Locking einfach genug hält, braucht man LOCK_NB gar nicht. Ich meine, wenn ich für alles nur eine einzige Datei komplett sperre und mich an das richtige Prozedere halte, dann brauche ich nie (!) Non-Blocking Locks.
Und bei allem, was komplizierter ist, muss man sich sowieso überlegen, ob man es nicht anders hätte realisieren können. Es gibt etliche gute Ideen, wie man Daten gleichzeitig auf der Platte ablegen kann, ohne, dass man mehr als bloß extrem simples Locking braucht.
Erzähle mir doch mal bitte von einem Standard-Anwendungsfall, bei dem Du meinst, nichtblockierende Locks zu benötigen. Wenn das nicht absolut konstruiert ist, bin ich mir sehr sicher, dass ich Dir ein alternatives Speicherformat vorstellen kann, das die Problematik nicht hat. Und weil es wenig gelockt werden muss auch noch den Vorteil hat, dass es besser skaliert (Locks sind da ja bekanntlich problematisch, weil sie, wie der Name schon so schön sagt, blockieren).
Viele Grüße,
Christian-
[latex]Mae govannen![/latex]
Ich höre mir dauernd den Kummer von Leuten an, deren Scripte nicht mehr (oder eben noch nicht wieder) laufen.
Huh? Ich habe File-Locking in PHP-Anwendungen in freier Wildbahn nur sehr, sehr selten gesehen. Nichtblockierende Locks noch weniger. Insofern kann ich diese Beobachtung absolut nicht nachvollziehen.
Kann natürlich immer sein, dass es Einzelfälle gibt. Aber "dauernd" kommt mir dann doch arg übertrieben vor.
Das ist ein spezielles "dauernd", wie in "objektorientierte Programmi" ... äh, ich muß weg ....
Cü,
--
Ash nazg durbatulûk, ash nazg gimbatul,ash nazg thrakatulûk, agh burzum-ishi krimpatul
selfcode sh:( fo:| ch:? rl:( br:< n4:# ie:{ mo:| va:) js:) de:> zu:) fl:( ss:| ls:?
Mein Selfhtml-Kram -
Hello,
LOCK_NB braucht man immer dann, wenn man Deadlocks vermeiden muss.
Nein. Wenn man sein Locking einfach genug hält, braucht man LOCK_NB gar nicht. Ich meine, wenn ich für alles nur eine einzige Datei komplett sperre und mich an das richtige Prozedere halte, dann brauche ich nie (!) Non-Blocking Locks.
*uff* und wieder einen Meter mehr Platz in meinem Bücherschrank.
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
-
-
-
-
Hallo,
Performance. Je nach Anforderungen kann bei größeren Datenmengen die Performance mit einer "echten" Datenbank nicht mehr mithalten (denke an z.B. 1000 Einträge, die Du mit PHP abarbeiten musst, um an Deinen Eintrag zu gelangen).
Das hängt aber auch stark vom Aufbau der Dateien und der Logik des Systems ab.
Ja. Das Problem ist aber schlichtweg, dass selbst wenn man mit PHP und Flatfiles eine effiziente Struktur umsetzt mit Indizes o.ä., dann muss das dennoch nicht effizienter als eine Datenbank sein. Warum? Datenbankentwickler beschäftigen sich ausschließlich mit dem Thema und wissen vor allem auch, wie sie aus verschiedenen Betriebssystemen die beste Performance beim Plattenzugriff und in der Speicherverwaltung erreichen und welche Caching-Strategien am besten geeignet sind. Ein normaler Entwickler (mich eingeschlossen) hat diese Hintergrundinformation einfach nicht - und kann sie vermutlich auch nicht so ohne weiteres einfach erwerben.
Daher: Zwar ist eine dem Problem angepasste, extrem spezifische Datenstruktur *theoretisch* gesehen performanter als eine generische Datenbank, allerdings haben wahrscheinlich die wenigsten Entwickler die nötige Erfahrung auf den relevanten Gebieten, um das dann auch praktisch umzusetzen. Ich halte es daher schon für angebracht, ab einer gewissen Datenmenge grundsätzlich auf eine Datenbank zu setzen, die einem die Arbeit abnimmt. Da kann man nämlich implizit auf die Erfahrung sehr vieler Experten zurückgreifen.
Viele Grüße,
Christian
-
-
Performance. Je nach Anforderungen kann bei größeren Datenmengen die Performance mit einer "echten" Datenbank nicht mehr mithalten (denke an z.B. 1000 Einträge, die Du mit PHP abarbeiten musst, um an Deinen Eintrag zu gelangen).
Ich sehe kein nennenswertes Problem. Auch bei 10000 Einträgen nicht.
Falls du eines siehst, solltest du deinen Umgang mit Flatfiles revidieren.mfg Beat;
-
-
Mahlzeit TetraPag,
Warum ich nicht mit einer mysql datenbank arbeite? Ich habe keine zur verfügung und möchte mir auch keine holen da ich eine flatfile möchte.
Was ist denn das für eine Argumentation? Hast Du als Alternativen XML-Datei(en) und SQLite in Betracht gezogen? Beide machen die Verwaltung erheblich einfacher, als wenn Du sämtliche Zugriffs- und Suchfunktionen selbst basteln musst ...
MfG,
EKKi--
sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:| -
Hallo,
der größte Nachteil von Flatfiles:
Es ist extrem viel mehr Aufwand. Bei größeren Projekte gerne gefühlt um den Faktor 100 oder 1000...Mit flatfiles zu arbeiten macht echt kein Spaß, da man echt alles selber schreiben muss. Angefangen bei selects, updates und inserts, zu Einschränkungen mit WHERE oder die Ergebnisse zu ordnen. Joins oder andere ähnliche Sachen kann man auch vergessen.
Eine entsprechende Klasse zu schreiben ist ein extremer Aufwand und ruck zuck baut man einen kleinen Fehler ein welches die gesamte Datenstruktur zerstört...
Wenn du kein MySQL nutzen möchtest (welcher Anbieter kommt ohne MySQL her? Selbst die billigsten Webspace Anbieter für 50 Cent haben MySQL dabei) wäre evt. SQLite noch eine Alternative (Sollte bei jeder PHP5 Version dabei sein).
Wie gesagt: Rate dringend von flatfiles ab. Ist viel zu viel Aufwand, langsamer, und auch sehr schwer zu programmieren.
-
ich bin gerade dabei ein kleinen Blog zu schreiben. Um dort komentare abzugeben oder sie zu lesen müssen sich user anmelden das ist kein problem. Da es sicher (und so soll es auch sein) nicht mehr als 50 user werden dachte ich mir ich nehme mir eine flatfile als datenbank. In die flatfile sollen je 4 informationen eines user gespeichert werden
- username 2. password 3. vorname 4. email (verschlüsselt) das ist auch kein Problem. Warum ich nicht mit einer mysql datenbank arbeite? Ich habe keine zur verfügung und möchte mir auch keine holen da ich eine flatfile möchte.
Ich rede bereits zu viel :D
Was ich eigentlich fragen möchte...
Welche nachteile hat eine flatfile?
Ein Flatfile an sich hat keinen Nachteil.
Die Datenstruktur, mit welcher du Daten-sätze Zeilenorientiert speicherst, kann Nachteile haben.
Speichere nicht nur Werte ab, sondern immer den Parameter zum WertBeispiel als XML
<parameter>Wert</parameter>Beispiel als CSV Dataseparator = ",\t"
parameter=wert,\tparameter=wert,\tAngenommen ich schreibe etwas wo ca. 5.000 oder mehr leute sich anmelden können kann sehr schnell etwas durcheinander kommen!
Chaos hat nichts mit der Anzahl der Daten zu tun, sondern mit schlechtem Design.
Datenzugriffe müssen natürlich ein Lockfile implementieren. Aber das hat nichts mit Flatfiles im speziellen zu tun.
In Perl gibt es Tie:File, ein Modul, welches mit grossen Files, oder Files mit unbekanntem Wachstumspotential fertig wird.Was ich bisher (ausversehen oder mit absicht) beobachtet habe:
- wenn man für jeden user nicht jeweils eine zeile benutzt gerät alles durcheinander so sieht man zum beispiel bei nummer 4 meines beispieles (email) alle informationen des nächsten user und er ist auch nicht mehr zu erkennen da der user ja eigentlich die email des vorherigen ist
Das deutet an, dass deine In/Out Zugriffe falsch konzipiert sind und/oder eine unglückliche Datenstruktur vorliegt.
- wenn beispielsweise vorname leer bleibt verrutscht die email auf platz 3 also bräuchte man einen platzhalter für nummer 3
Leere Werte sind Werte. Warum speicherst du diese nicht? Warum liest du sie nicht als gültige Werte aus?
Speicher parameter, und du weist, wofür ein Wert steht, egal in welcher "Spalte" des Records er steht.- im schlimmsten fall können fremde leute die flatfile in ihrem browser aufrufen und sie anzeigen lassen
Speichere das File ausserhalb von DocumentRoot.
mehr fällt mir gerade nicht ein. Natürlich kann man mit einigen abfragen und sicherheitsvorkehrungen die punkte 1-3 sichern. Aber ich kann mir nicht vorstellen dass es bei mehr als 5.000 usern noch efizient ist oder doch?
Doch, sehr sogar...
Wer hat damit schon erfahrungen gemacht? Wer weiss noch mehr nachteile einer Flatfile?
Ich zu genüge und bin vollauf zufrieden. Ich habe nicht 500 User, aber die Datenstruktur in Memberfiles und anderen Datenfiles ist grundsätzlich immer die Gleiche. Einige Datenfiles haben über 10000 Records.
mfg Beat;
- username 2. password 3. vorname 4. email (verschlüsselt) das ist auch kein Problem. Warum ich nicht mit einer mysql datenbank arbeite? Ich habe keine zur verfügung und möchte mir auch keine holen da ich eine flatfile möchte.
-
Hallo,
Welche nachteile hat eine flatfile?
für eine Mini-"Datenbank" (in meinem Fall ist es eine einzige Tabelle) hat ein Flatfile durchaus seine Berechtigung.
Außerdem lassen sich die Vorteile von SQL und Flatfiles durchaus verbinden ...
Für ein Gästebuch tut seit Jahren http://www.c-worker.ch/txtdbapi/index.php gute Dienste.HTH
Jochen
-
Hi,
- wenn man für jeden user nicht jeweils eine zeile benutzt gerät alles durcheinander so sieht man zum beispiel bei nummer 4 meines beispieles (email) alle informationen des nächsten user und er ist auch nicht mehr zu erkennen da der user ja eigentlich die email des vorherigen ist
und worin siehst Du ein Problem, wenn Du Dich z.B. für das csv-Format entscheidest, pro User eine Zeile anzulegen?
- wenn beispielsweise vorname leer bleibt verrutscht die email auf platz 3 also bräuchte man einen platzhalter für nummer 3
dann hast Du, wie bereits gesagt wurde, den Fehler gemacht und das leere Datum nicht gespeichert.
- im schlimmsten fall können fremde leute die flatfile in ihrem browser aufrufen und sie anzeigen lassen
nö. Entweder Du speicherst die Datei wie vorgeschlagen außerhalb des DocumentRoot, oder Du benennst sie einfach mit ".ht" am Anfang.
mehr fällt mir gerade nicht ein. Natürlich kann man mit einigen abfragen und sicherheitsvorkehrungen die punkte 1-3 sichern. Aber ich kann mir nicht vorstellen dass es bei mehr als 5.000 usern noch efizient ist oder doch?
doch - sofern Du effizient programmierst. Bei sehr vielen Usern könntest Du die Performance z.B. durch Aufteilung in mehre Dateien steigern, z.B. .htUserA bis .htUserZ oder gar ein binäres Speicherformat zu wählen mit festen Feldlängen und Indizes und dann direkt auf einen "Datensatz" zu positionieren.
freundliche Grüße
Ingo -
Meines Erachtens hat eine Flatfile ne Menge Nachteile (z.B. oben erwähnte) wenn man nicht genau damit umzugehen weiss.
Ich selbst arbeite nicht mit PHP sondern mit PERL aber bei dieser frage denke ich ist es irrelevant mit was man dies realisiert.
Vor kurzem erst hatte ich für einen bekannten einen Mitgliederbereich (Anmeldung, Verwaltung, Login etc.) programmiert, das alles bassiert auf einer Flatfile. Die Flatfile ist jedoch im gegensatz zu deinem Beispiel besser optimiert.
Deine Flatfile sieht so aus:
-----
1. username 2.passwort 3. vorname 4. email
-----
Meine Flatfile würde so aussehen:
-----
<username>username</username><password>passwort</password> usw.
-----Ich denke mal um an die Userinformationen ranzukommen splittest du bei 1. / 2. / 3. / 4..
Was wäre wenn jetzt jemand als Username: "TetraPag der 2." nimmt? Merkst was? - Arbeite am Design.Deine frage ist verständlich, als ich den Mitgliederbereich realisierte stand ich auch vor der frage "Flatfile oder 'echte' Datenbank?", als ich aber zu hören bekam, dass es bestimmt nicht mehr als 100 Mitglieder werden und nur jeweils 6 Userinformationen pro User gespeichert werden sollen hatte ich keine bedenken mehr. Natürlich hab ich dennoch mein ganzes "wissen" angewandt um es bestmöglichst zu machen. Kurz vor Ende kamen dann noch änderungen dazu: jeweils 10 Userinformationen pro User, "eigenes Profil ändern"-System, erweitertes Verwaltungssystem mit Moderatoren-nutzung etc. - da kam ich schon ins grübeln ob ich nicht lieber doch mit ner Datenbank arbeiten möchte, ich habe es aber dann trotzdem so gelassen bzw. das Budget machte nicht so mit ;D.
...
Inzwischen hat die Seite über 600 Mitglieder mit relativ hoher aktivität und seit Anfang an (etwa 1 1/2 Monate) gab es bisher nur ein Problem damit und das war (wie oben angesprochen) ein "Leerfeld"-Fehler (der eigentlich nicht passieren hätte dürfen), sprich: vorname wurde beim anmelden nicht definiert <vorname></vorname> und tatsächlich rutschten die anderen Informationen einen Schritt vor. Ich habe also einfach nur vergessen, dass wenn beim Anmelden der vorname nicht angegeben wird einen platzhalter zu setzen.
Mit Platzhalter meine ich eine bestimmte Zeichenkette die bei undefinierten Inhalten hineingeschrieben werden und diese bei der Ausgabe "unsichtbar" gemacht werden (gibt bessere möglichkeiten!). Du musst jedoch dann bei jedem Schritt (bspw. Profil-änderung) daran denken, dass du Platzhalter benutzt.Wenn man sich über alles bewusst ist (auf was muss ich achten, was kann passieren und wie kann ich es vermeiden, struktur etc.) ist eine Flatfile durchaus akzeptabel. Für die "einfachkeit" sollte man sich dann aber dann doch lieber für eine Datenbank entscheiden.
-
Hello,
wenn eine Applikation alleine mit der dateio arbeitet, sie also nicht auf Datenaustausch angelegt ist, dann würde ich für derartig strukturierbare Information immer eine Random-Access-Datei nehmen (Feste Feldlänge, feste Satzlänge) und kein XML-File, das dann ja variante Feld- und Satzlänge hat.
Der Verlust an Bytes ist bei derartigen Informationen verschmerzbar. Der Gewinn an Geschwindigkeit ist hingegen enorm. Außerdem muss die Datei auch nicht mehr vollständig in den Hauptspeicher passen; diese Forderung ist bei der anderen Variante zumindest mit sehr viel mehr Aufwand verbunden.
Und man kann die Daten jedes Datensatzes _direkt_ ändern, ohne die ganze Datei umkopieren zu müssen.
Problematisch ist es bei Flatfiles nur, eine quasi-atomare Operation aus Verwaltung des Datenfiles und Führung des Indexfiles zu bauen. Ohne Indexfile wird die Datenverwaltung bei größeren Beständen sonst auch schnell lästig langsam.
Und wie komplex Indexverwaltung werden kann, das ist ein Thema für sich. Damit sSollte man sich aber auf jeden Fall mal beschäftigt haben :-)
Liebe Grüße aus Syburg bei Dortmund
Tom vom Berg
-
-
Hi!
Du hast ja jetzt schon eine Menge Antworten erhalten (wenn auch viele davon imho mit Fach-Chinesisch vollgestopft sind und von Projekten ausgehen, die mit dem geschilderten Fall wohl mehr als unwahrscheinlich sind).
Beim Durchlesen hatte ich aber den Eindruck, dass kaum einer mal die Vorteile von Flatfiles herausgestellt hat.
Ich bin nun leider auch nicht der Experte auf dem Gebiet, aber ich versuch's mal (wenn etwas falsch sein sollte, dauert es eh meist nur 5 Minuten, bis es jemand richtig gestellt hat - also bitte 5 Minuten warten ;-) ).
Auch wenn es heutzutage quasi Standard ist, so ist ein wesentlicher Vorteil von Flatfiles, dass man eben genau keinen DB-Server braucht. Somit ist ein darauf basierendes Projekt sehr leicht und einfach zu portieren (von einem Server auf einen anderen) und auch ein Backup ist sehr einfach erstellt.
Bei einer eher einfachen Datenstruktur (wovon ich hier mal ausgehe) sind spätere Anpassungen und Änderungen u.U. sogar einfacher, als wenn man den ganzen DB "Overhead" noch mit dranhängen hat.
Ich selbst betreibe ein kleines Wiki, welches auch nur rein mit Flatfiles arbeitet. Ist ein recht bekanntes und weit verbreitetes Wiki-Skript: DokuWiki
Na und deine 3 Punkte haben sich ja auch schon erledigt durch die anderen Beiträge.
Bezüglich Performance würde ich mir bei deinem Vorhaben jedenfalls auch keinen Kopf machen. Wichtig ist eben nur eine effiziente Programmgestaltung und entsprechende Optimierung der Datenstruktur - schönes Lernbeispiel. Und wenn du später mal Langeweile haben solltest, kannst du es ja zusätzlich auch noch mal mit einer richtigen DB probieren und die Performance vergleichen! ;-)
Viel Erfolg jedenfals bei der Umsetzung!
Gruß Gunther
-
echo $begrüßung;
Auch wenn es heutzutage quasi Standard ist, so ist ein wesentlicher Vorteil von Flatfiles, dass man eben genau keinen DB-Server braucht. Somit ist ein darauf basierendes Projekt sehr leicht und einfach zu portieren (von einem Server auf einen anderen) und auch ein Backup ist sehr einfach erstellt.
Man braucht auch keinen dedizierten Datenbankserver, wenn man SQLite einsetzt[1]. Man umgeht damit aber einige Probleme, die man mit Flatfiles selbst lösen muss. Das Konzept Flatfiles hört sich einfach an, aber das nur auf den ersten Blick. Man übersieht dabei gern, dass man viele Nebenwirkungen zu beachten hat, die der Datenbankserver bereits gelöst hat, besonders wenn man früher mit einem DBMS gearbeitet hat und sich nur der "Nachteile" wegen Gedanken über eine Alternative macht, die Vorteile aber weniger stark wichtet.
Eine SQLite-Datei ist genauso leicht zu portieren wie ein Flatfile. Ein Backup ist ebenfalls mit einem Kopiervorgang erledigt.
Meines Erachtens ist SQLite ein guter, wenig bekannter Kompromiss zwischen dateibasierter Speicherung und einer ausgewachsenen Datenbank.
Bei einer eher einfachen Datenstruktur (wovon ich hier mal ausgehe) sind spätere Anpassungen und Änderungen u.U. sogar einfacher, als wenn man den ganzen DB "Overhead" noch mit dranhängen hat.
Das Lesen der alten und Schreiben einer neuen Datei mit geänderter Struktur soll einfacher als ein ALTER TABLE-Statement sein? Wie begründest du das? Was verstehst du unter DB-Overhead in dem Zusammenhang?
[1] Es gibt auch SQLite unter PHP. Ab PHP 5.3 auch in der Version 3.
echo "$verabschiedung $name";
-
Kritzeln statt texten: