Ja, ich muss zugeben, mittlerweile bin ich auch dem NW untreu geworden. Ich habe jetzt mein eigenes Redaktionssystem auf MySQL-Basis gebastelt - nicht zuletzt, weil auch das zugreifen auf die Artikel wesentlich unkomplizierter ist, als beim NW System...

Die Commentsadministration, Bewertungskript etc. kann man alles ganz bequem per MySQL erledigen... nur eine Pipeline für Artikel hat bis dato noch nicht geklappt...
 

Nur _EIN_ User genügte??? Was war sein Argument, Basti?  

Neugierig: Ralph

Also, solange die SQL funktion OPTIONAL ist, hab ich gar nichts dagegen.
Auf großen Seiten ist das sicher von Vorteil.
Auf kleineren Webpaketen bei 1und1 ist IMO jedoch nur PHP, aber kein SQL inclusive und für einige Kunden brauch ich da trotzdem ein kleines Newssystem. Genau das was der Newswriter bisher geboten hat.
Also bitte die bisherige Funktion nicht entfernen.

Was im Zuge der SQLliesierung natürlich sinnvoll wäre - Ein IM/EXport Tool für den File/Db umbau. Ich denke es gibt viele die schon enorme Datenmengen im Newswriter verarbeitet haben.

Ein anderer Aspekt bei MySQL-basierten Skripten wird von den Usern meist vergessen: Datensicherung und lokale Tests.
Eine MySQL-basierte Site lokal zu testen, ist schon eine Wissenschaft für sich. Da muß man nicht nur den Apache-Webserver zum Laufen bekommen, sondern auch den MySQL-Server. Und wenn dann mal alles läuft, beginnen die Schwierigkeiten erst. Da man MySQL-Datenbanken normalerweise nicht per FTP sichern kann, muß man für Datensicherungen den Umweg über Phpmyadmin gehen. Dieser beliebte MySQL-Manager scheitert aber an Sicherungen, die größer als 2 MB sind. Zudem werden die Daten in ein Textformat konvertiert und müssen wieder mit Phpmyadmin (lokal) eingelesen werden.
Auch wenn viele einen lokalen Betrieb der Website für unnötig halten (das lästige Hochladen per FTP nehmen die meisten dann in Kauf), kommt doch die Stunde der Wahrheit, wenn der Internet-Server mal crasht und man hat kein (MySQL-)Backup - oder die Domain zieht um und man weiß nicht wie man die MySQL-Daten unfallfrei auf einen neuen Server bekommt.
Das wäre alles kein Problem, wenn die Hoster die MySQL-Datenbanken im für FTP zugänglichen Bereich ablegen würden. Eine Datensicherung und -wiederherstellung per FTP ist dann kinderleicht.

Genau das sind die Punkte, weshalb ich bei meiner Website nur im Notfall auf MySQL-Skripte zurückgreife. Zum Beispiel würde ich bei einer Indizierung (für eine Suche) der Website auch ein MySQL-Skript nutzen, weil da die Daten nicht unbedingt sicherungswürdig sind. Leider scheiterten bisher alle MySQL-basierten Indexer an der Größe meiner Site (500 MB, ca. 1700 "statische" Seiten und mehrere tausend  dynamische Inhalte), weil sie sich irgendwann einfach weghängten.

Das statisch steht deshalb in Anführungszeichen, weil die Website mit phpCMS läuft.

JA!

Ich denke auch, dass die Grundidee der Textfiles ja eine sehr alte Idee ist (10 Jahre?) und aus einer Zeit stammt, als mySQL noch teuer beim Hoster extra bezahlt werden musste. Das ist heute nicht mehr so und niemand würde wohl vor diesem Hintergrund noch mal ein CMS mit Flatfiles aufsetzen. Dafür ist es dann doch zu unflexibel.

Um den NW in eine mySQL Version zu übersetzen ist natürlich eine Konvertierung der vielen alten Artikel aus den Textfiles in die mySQL-Tabelle unbedingt erforderlich, denn die bisherigen Anwender sollen ja wohl sicher mitgenommen werden.

Zumindest diese Konvertierung habe ich für meine Seite www.Berlin-Bookmarks.de ( > 1000 Artikel seit 2001) bereits Ende 2007 gelöst, seitdem fahre ich sozusagen zweigleisig.
 
Vereinfacht erklärt funktioniert der Mod so: beim Erstellen eines neuen Artikels werden die Artikelelemente gleichzeitig in eine mySQL Table eingefügt.

Wird ein Artikel geändert, wird der alte Datensatz entfernt und unter Beibehalt der Zähler wieder als neuer Datensatz angefügt.

Wird vom Leser ein alter Artikel aufgerufen, wird überprüft, ob er schon in der DB enthalten ist, gfls. dann vom modifizierten article.php angefügt.

Mit den Datenbank Artikel lassen sich prima ganz einach neue Sortierungen und Selektionen einrichten (meist gelesene, alle Headlines, nach Datum etc) und vor allem einen interne Suchmaschine darauf ansetzen.

Im Prinzip lassen sie die alten Texte dann natürlich auch mit wenig Aufwand in ein völlig anderes CMS (Typo3 etc) übertragen.

Grusz
Ralph