webazubi

Hallo.
Ich will, nachdem ich zehn Jahre lang fürs Papier geschrieben habe, eine Internetzeitung aufbauen. Dazu suche ich einige Anregungen bzw. Verbesserungsideen.

Mein Vorhaben, wie ich es bislang geplant (und auch schon erfolgreich getestet habe):

1.
In eine MySQL-Datenbank werden die Schlagzeilen erfasst, dazu natürlich alle Verknüpfungen zu Autor, Schlagwort, Thematik usw.

2.
Die einzelnen Texte, egal ob Kurzmeldung oder Artikel, werden als Textdateien im XML-Format gespeichert und sind über PHP/MySQL abrufbar.

Folgende Überlegungen führten mich zu dieser Herangehensweise.

zu 1: Datenbank ist klar, aber ich will nicht alle Texte, sondern nur die Schlagzeilen erfassen, da ich

a) sonst die Datenbank schnell voll hätte mit (alten) Texten, die ich zwar nicht wegschmeißen, aber auch nicht immer mit mir herumschleppen will. Wenn der "Datenmüll" nur als TXT vorliegt ist es einfacher zu handeln (nur bestimmte Dateien hochladen bzw. Dateien nur auf Anfrage zur Verfügung stellen). Oder wäre das mit MySQL-Auslagerungen genausogut zu handhaben?
b) schlechte Erfahrungen mit rein auf MySQL-basierten Applikationen habe, denn wenn der Datenbankserver ausfällt, liegt auch die Seite lahm. Das will dadurch umgehen, dass eine textbasierte Version, aus der Beispielsweise regelmäßig alle MySQL-Schlagzeilen exportiert werden und bei Ausfall per Link direkt aufgerufen werden können, als Alternative angeboten werden soll.
Zumal ohnehin die Frage nach der Barrierefreiheit bzw. Handylesbarkeit besteht. Da ich auch noch ein Forum einbauen will (wahrscheinlich PHPBB) und im Zuge dessen bereits viele Probleme was die Barrierefreiheit betrifft sehe, scheint mir die Überlegung einer rein textbasierten Alternative (unter Umgehung von MySQL) vernünftig zu sein. Natürlich mit Verlust von bestimmten Funktionen.

zu 2: XML als Dateiformat will ich haben wegen der Auszeichnungsmöglichkeit (Tags) sowie der weiteren optionalen Verarbeitung in entsprechenden Layoutprogrammen (InDesign, Quark). Dabei habe ich folgende Frage:
Soll ich die XML-Definition wirklich in jede XML-Datei reinschreiben? Die Datei wird ja ohnehin per PHP geparst - meine jetzige Herangehensweise sieht so aus, dass ich per Script die XML-Tags durch CSS-Tags ersetze, da ja nicht alle Browser mit der direkten Umsetzung des XML in Stylesheets klarkommen.
Daher bräuchte ich zumindest für meine Webseite die XML-Definition nicht zwingend in jeder Datei - es sei denn, ich will sie später in anderen Programmen nutzen, die den Header entsprechend erwarten.
Warum die Definition nicht überall mit reinschreiben? Einmal wegen des (unnötigen) Platzverbrauchs (klar, sind nur wenige Bytes, aber ich will eine tagesaktuelle Zeitung machen, wo jede Kurzmeldung mit dem XML-Gerüst versehen werden müsste).
Zumal ich eine einfache XML-Struktur habe (Dachzeile, Headline1 usw.), wo ich doch bestimmt in 5 Jahren vor dem Problem stehen werde, dass ein dann aktueller Browser nur XML ab Version 3.0 lesen kann, wo ich dann per Hand (bzw. Batch) alle Dateien auf die Versionsinfo ändern müsste.
Und irgendeine Funktion, die mir bei Bedarf in alle XML-endenden Dateien in die erste Zeile den XML-Aufruf reinschreibt, werde ich doch bestimmt finden.
Also: XML reinschreiben oder nicht?
Und wie verhält es sich eigentlich mit Volltextsuchen in XML-Dateien? Meine ersten Versuche liefen mit TXT-Dateien, in denen es keine TAGs gab, die eine Suche oder deren Ergebnisse negativ beeinflussen würden. Bei XML werde ich aber sicherlich auch nur per PHP häppchenweise Dateien zur Suchen einlesen und kann diese dann xml parsen, bevor die Suchroutine aufgerufen wird, oder?

Weitere Fragen:

Meine Idee bislang sieht vor, dass ich mit Word 2003 die XML-Datei erstelle. Word deswegen, weil es sich bei den reinen Funktionen für die Textverarbeitung auszeichnet. Auch die XML-Funktionen reichen offenbar aus um mein Vorhaben umzusetzen.
Probleme habe ich derzeit nur bei der Einbindung von Bildern und was die entsprechende Definition in der zugrunde liegenden XSD-Datei betrifft. Außerdem strukturiert Word das fertige XML nicht so schön wie reine XML-Editoren (ich meine nicht die Baumansicht, sondern die Absätze nach jedem Tag). Aber das ist wohl nur eine Frage der Transformation.

In diesem Zusammenhang frage ich mich, ob es sinnvoll wäre, die Bildunterschriften in die MySQL auszulagern. Schließlich kann ein und dasselbe Bild mehrere Beschreibungen haben und in unterschieldichen Artikeln auftauchen.
Wäre natürlich kein Problem, am Ende der geparsten XML-Datei abzufragen, ob es für diesen Artikel (mit einer bestimmten ID) ein oder mehrere Bildunterschriften gibt und die dann am Ende samt des Bildes einzufügen. Dann hätte ich allerdings alle Bilder nur am Ende und nicht im Artikel.

Das könnte ich dann mit einem XML-Tag innerhalb des Textes ändern nach dem Motto <bildtext>XXX</bildtext> und dann über PHP bzw. MySQL: Wenn <bildtext> = XXX dann suche in der Datenbank nach der Nummer dieses Artikels und ob es dafür eine Bildunterschrift gibt.

Doch das scheint mir doch etwas umständlich zu sein. Bei der späteren Verarbeitung der XML-Dateien in Layoutprogrammen (ohne PHP und MySQL) würden die Bildunterschrift schlicht fehlen, sofern ich die Tags nicht ähnlich dem Verfahren bei dem Einfügen der XML-Definition per Hand vollziehe.

Das Bild an sich kann ich ja noch per URL-TAG angeben, aber bei der Bildunterschrift fehlt mir noch die Lösung. Zumal ich es ohnehin gerne einem PHP-Skript überlassen würde, wo es die Bilder samt Beschreibung im Text platziert, nach dem Motto: Ich XML-Datei bin (abzüglich meiner XML-Tags) 3.000 Zeichen lang und mir sind 3 Bilder zugeordnet, also packe ich die alle 1000 Zeichen (plus/minus X damit nicht mitten im Wort getrennt wird) ein Bild rein, das sich rechts und linksbündig abwechselt. Wenn das klappen würde, bräuchte ich überhaupt gar keine Bild-XML-Tags mehr in meiner Textdatei!

So weit erstmal. Kann mir jemand noch einen Tipp geben? Bei der Umsetzung einzelner Sachen werde ich sicher noch an anderer Stelle Detailfragen stellen.

Mister Ad

Flor1an

Hi

also ich würde wenn dann alles in einer MySQL Datenbank speichern.
Dadurch hast du deine Daten kompakt gesichert und kannst wesentlich einfach drauf zugreifen.

Deine Argumente mit dem Ausfall der DB hast du ja selbst enthebelt. Wenn du die Schlagzeilen per DB speichern willst kannst du bei einem Ausfall der DB auch nicht auf die Schlagzeilen zugreifen. Außerdem kommt ein Ausfall der DB eigentlich nicht vor, da müsste schon der Server schlecht konfiguriert sein oder die Last einfach ZU groß. Und wenn dies der Fall wäre hast du mit Textdateien sowieso schon keine Chance mehr.

Ein Backup der Mysql ist einfacher als wenn du die Textfiles jedes mal backupen müsstest und dazu die Schlagzeilen aus der MySQL. Oder wie du gemeint hast die Schlagzeilen immer neu generieren etc.

Auch mit deinen Bildunterschriften würde ich eine DB vorziehen. Du speicherst für jedes Bild den Pfad und die Unterschrift dafür. Alles andere wäre meiner Meinung nach zu umständlich.

webazubi

Glückwunsch zum Abi - und offenbar schon wieder nüchtern?!


Wenn ich täglich eine TXT-Datei generiere, die die Schlagzeilen und die dazugehörigen IDs auswirft, kann ich die notfalls einlesen. Alle Texte werden ohnehin nur durch eine Ausgabe.php geschliffen bzw. includiert. Da kann ich dann sagen: Wenn SQL nicht reagiert, greife auf die Textdatei zu, ermittel die gewünschte ID und lade die entsprechende Datei (die mit der ID als Dateinamen beginnt).

Bei strato habe ich den Fehler gemacht, ein phpBB-Forum mit MySQL als Startseite festzulegen. Mindestens 3x ist mir der strato-SQL-Server abgeschmiert und ich konnte nur noch per FTP eine neue Startseite (ohne SQL-Aufruf) hochladen. Also nie wieder das Forum als Startseite!

Das mag sein. Nennt sich "Premium-Paket" bei strato. Der Support klappte wenigstens.

Nach einem Jahr habe ich da 3/4 Müll drin, den ich nur selten brauche. Da würden mir die Schlagzeilen reichen. Und die Dateien will ich per Script löschen bzw. backuppen. Das kann nicht so umständlich sein. Zumal ich die "Laufzeit" einer Meldung ohnehin in der DB speichere.
Ja, sehe ich ähnlich, aber damit zerschieße ich natürlich die XML-Datei bzw. lagere Teile aus. Am besten ich mache beides: Primär die DB-Abfrage nach Bildern aber auch einen entsprechenden Tag, falls die XML ohne PHP/MySQL ausgelesen wird.

daniel987

Ich würde auch in jedem Fall eine Datenbank den Dateien vorziehen zum einen vermute ich nicht das du soviele Daten speicherst, das Mysql wirklich viel langsamer wird. Falls doch bau halt ein Crownscript, dass dir einmal im Monat oder meinetwegen auch einmal pro Woche alle alten Beiträge in eine 2 Archiv Datenbank schiebt.

Basti

Hi.

Der Punkt wurde ja schon dikutiert, aber hier nochmal meine Sichtweise (incl. Wiederholungen):

Wichtig sind hier die Aspekte Performance (Lesezugriffe), Volltextsuche, Archivierung, Portierung, Zugriffsrechte und Konsitenz (was noch?)

Um die Daten zu archivieren reicht dir bei reinen Textdaten auch kein enfach FTP-Client, da du sie Dateien ja selektieren musst. Folglich müsstest du dir ein Skript bauen, mit dem du die Daten nach bestimmten Kriterien auswählen kannst (Alter, Besucherzahlen, whatever) und das dir die Dateien kann kopiert, komprimiert oder eben beides tut.

Ich denke, hier bringen Datien nicht wirklich einen Vorteil, kann as aber auch nicht belegen. Ob du die Daten jetzt von Order aktuell ind Ordner archiv verschiebst oder von Datenbank aktuell nach Datenbank (oder auch nur Tabelle) archiv macht wenig unterschied, außer vom Gesichtspunkt der Komprinierung her - denn binäre Daten machen in einer Datenbank ja wenig Sinn.

Wie sich eine Volltextsuche mit XMLDatengestaltet, dazu kann ich auch wenig sagen. Ich denke aber, der geschickteste Weg wäre einen Index anzulegen, ggf. mit Cache für häufig eingegebene Einzelbegriffe oder so.

Zur Portiertung und Datenkonsistnz, ich denke, da ist es immer einfacher, die Daten beisammen und nicht auf verschiedenen Systemen (FS und DBMS) verteilt zu haben. Die Daten machen nur zusammen Sinn und mit einer reinen Datenbank-Lösung lassen sich Transaktionen sicher leichter umsetzen, als mit einem gemischten System, bei dem du dann z.B. abgeschlossene Datenbank-Queries wieder zurückrollen musst, wenn auf dem FS plötzlich kein Platz mehr ist oder sonst ein Fehler auftritt oder umgekehrt.

Wenn die Daten mit Zugriffsrechten (auch nur, wenn dein Workflow vorsieht, dass Artikel erst freigegeben/veröffentlicht werden müssen, es verschiedene Versionen gibt (z.B. bei der gemeinsamen Erstellung etc.)) versehen werden sollen, dann muss ohnehin jeder Lesezugriff zunächst über die DB laufen. Du hast da also keinen Perfomancegewinn durch direkten Zugriff auf die XML-Dateien (für Clients, die damit was anfangen können).

Soweit ich weiß, macht es sich ungünstig, wenn einzelne Tabellenspalten in Datenbanken viele Daten enthalten. Wenn denn das stimmt, wäre es ungünstig, die Texte mit viel nachgeschlagenen Metadaten zusammen in eine Tabelle zu packen. Aber da bin ich nich bewandert, hatte bislang noch nichts mit sehr großen Datenmengen am Hut, dass ich mich darüber hätte schlau machen müssen.

Es gibt aber viel Futter im Netz und in Büchern zum Thema Datenbankoptimierung zwecks schnellen Zugriffszeiten.

Ich würde hier ohnehin ein (ggf. mehstufiges) Caching-Konzept vorschlagen. Zumindest, wenn die Zugriffe keine Authentisierung erfordern und häufig an normale Web-Browser gehen, dann solltest du die Daten nach der XSLT-Umwandlung speichern.

Apropos XSLT: Das wäre übrigens der übliche Weg, XML z.B. in HTML umzuwandeln. Lies dich da mal ein, das lohnt sich allemal.

Den Zusammenhang kann ich nicht erkennen. Beziehungsweise eher umgekehrt. Wenn du z.B. Bild-Infos in der Datenbank hälst und später darauf kommst, dass da ja alt-Tags zu füttern sind oder Links, die dann mal titles und descriptions brauchen, dann lässt sich eine Datenbank einfacher mit solchen zusätzlichen Attributen füttern, als XML-Dateien. Und o die Dann liegen ist für diesen Punkt ja eh Schnuppe.

Kommt daruf an, was du willst bzw. wie du aufdie Daten zugreifst. Wenn die Daten in Dateien liegen, die für sich vollständi sein sollen, dann gehört da natürlich diese Zeile rein, sowie auch der Verweis auf die DTD.

Andernfalls ist es Wurscht, denn du kannst die Daten ja jederzeit dynamisch ergänzen lassen.

Ich vermute, bei den Datenmengen (hört sich zumindest nach viel an), wäre es abslut untauglich, für jede Suche alle XML-Daten durch expat zu jagen oder entsprechende DOM-Objekte davon zu erzeugen, um diese zu durchforsten.

Ich würde da eben eher einen Index anlegen, in dem du die Wörter (natürlich nicht die 'und', 'die', 'hat' etc.) ggf. mit Wichtung Artikeln zuordnest.

Kann mir ja nur schwer vorstellen, dass sich MS Word dafür eignet, aber warum nicht? Ist aber letztlich Wurscht, denn wenn du die Daten hast, kannst du sie ja mit beliebigigen Editoren bearbeiten.

Die Frage ist ja eh, wie die Artikel erstell werden und dann ins Nez kommen. Ist ja vielleicht ein bischen Umständlich, die per ftp oder ssh hochzuladen, per cronjob entgegenzunehmen und ggf. dann beim nächsten Login noch mit den benötigten Angaben bestücken zu lassen.

Wenn jeder Artikel für das selbe Bild eine andere Unterschrift hat, dann gehört diese in den Artikel bzw. die Zuordnungstabelle Artikel-Bilder. Gibt es mehrere Unterschriften, die je auch mehrfach verwendet werden, dann würde ich diese beim Einbinden des Bildes als Option mit zusätzlicher Option, eine weitere Unterschrift einzubinden anbieten - zumindest natürlich, wenn du die Artikel über ein Web-Frontend erstellst.

Bleibt die Frage, ob diese Unterschriften dann einfach nur in die Artikel abgeschrieben werden oder diese nur eine Referenz auf die Unterschrift erhalten sollen.

Da spielen zu viele unbekannte Faktoren mit. Wenn du die Unterschriften später für alle "Instanzen" dieser Unterschrift in allen Artikeln ändern möchtest, dann baruchst du eine Referenz. Andernfalls nicht. Wenn die Artikel in sich konsistent sein sollen, dann funktioniert eine Referenz auf die Datenbank natürlich nur, wenn diese auch verfügbar ist oder eine entsprechende Shnittstelle bietet, die dann verfügbar ist.

Liebe Grüße,
Basti

Zergling-new

Ich kann mich da eigentlich nur anschließen, auf einen Mischmasch zwischen XML und MySQL würde ich verzichten. Allein schon wie erwähnt die Suche innerhalb von XML-Dateien und die korrekte Zuordnung gestaltet sich einfach unkomfortabler als bei einer Datenbank. Vorteil sehe ich bei XML jetzt eigentlich nicht.

Wenn du mit Strato nicht zufrieden bist, wechsel eben den Anbieter oder leg dir gleich einen eigenen Server zu.

Bevor du aber mit Programmieren loslegst, empfehle ich dir alles nochmal ganz genau zu planen und zu konzeptionieren, ein paar Schlampereien und du hast am Ende einen riesen Salat, der dich unglaublich Arbeit kosten kann.

Von solchen "automatisierten" Gestaltungen halte ich eigentlich eher weniger, da sie vielleicht für die ersten 9 Artikel passen, aber bei jedem 10 geht es dann schief und dann kommt die große Verschlimmbesserei im Code.

Zum Thema Archivierung: Artikel die wenig gelesen und noch dazu älter als X Wochen/Monate sind, einfach automatisiert in ein Archiv schieben, sehe da aber auch keine Probleme.

webazubi

Hallo Leute.
Hmm, meint Ihr echt, alles in MySQL statt "Mischmasch" mit XML-Dateien? Gefällt mir gar nicht. Zumal ich noch X Anlagen wie Bilder, PDFs usw zu einzelnen Artikeln habe, die ich dann ja konsequenterweise auch noch einsqllen müsste. Die Referenzierung auf externe Dateien zu einzenen Meldungen scheint mir unausweichlich.
Ich werde aber schauen, ob ich nicht aus den einzelnen Text- bzw. XML-Dateien bestimmte Elemente mit in die MySQL übernehme, so dass bestimmte Funktionen schneller ablaufen. Also neben Titel 1, Untertitel auch den Vorspann sowie einzelne Stichwörter zu den Texten.

Das mit der Volltextuche ist wohl das größte Problem, aber in der Anfangsphase bleiben die Dateien überschaubar und später reicht das Geld vielleicht für einen eigenen Server, bei dem das MySQL-Skript nicht sofort bei entsprechendem Datenvolumen zusammenbricht.
Zumal somit auch die Offline-Dateien, die also aus Speicherplatzgründen nicht mehr auf dem Server lagern, erfasst wären (und bei Bedarf angefordert werden könnten).
Na bislang dachte ich den Artikel in der Pressekonferenz zu schreiben, auf dem Notebook mit phpmyAdmin den Datensatz zu erstellen (bzw. alle zu dem Datensatz gehörigen Zuordnungen über ein MS Access - Formular SQL-tauglich auszugeben), das alles zusammen mit der Text bzw. XML-Datei hochzuladen und fertig ist. Schön wäre noch ein Telnet-Zugang, dann könnte ich auf phpmyAdmin verzichten un das SQL-Skript gleich von Access heraus starten.

Machen ja aber nicht alle Browser, sonst hätte ich das schon längst implementiert. Stattdessen muss ich mühsam css und XML herauslesen, was zumindest bei XML-Elementen mit Unterlelementen ziemlich umständlich ist.

Ich betreue dort nur für jemanden eine Seite.
Zu spät. Ich lerne offenbar lieber durch Misserfolg

Zum Thema "Automatischer Spaltenumbruch"
Und da wird eben wieder XML interessant, denn einige Störfaktoren beim Spaltenumbruch können vermieden werden. So suche ich ja nach der halben Zeichenanzahl nach dem darauffolgendem Satzende, was schief geht, wenn beispielsweise ein Datum ähnlich formatiert ist wie das Satzende (bzw. der Satzanfang mit PUNKT FREIZEICHEN). Ist ein Datum wie der 15. Dezember 2006 hingegen mit XML getaggt, würde die Satzanfangssuche darüber hinweggehen.
Aber gut, Tags schreiben könnte ich auch in MySQL.

Ich werde erst mal die Variante ausbauen, testen und dann wieder darüber berichten. Vielen Dank vorerst für die Vorschläge.

Basti

Hi.

Ja, klar. Da kommst du nie drum rum, dass du auch Daten auf der Platte hast. Nur ist es einfacher zu verwalten, wenn da eben nur Downloads und eingebettete Medien-Files (Bilder etc.) liegen, als auch noch Texte. Aber letztlich ist das auch halbwegs Wurscht, wo die Daten liegen. Die Frage ist halt, für welche Zugriffe das System optimiert werden muss und was dann mehr Sinn macht.

Um XML oder eine andere Auszeichnungssprache kommst du ja auch nicht drumrum, aber ich halte es so, dass ich nur Texte, die eben ausgezeichnet werden müssen in einer solchen Auszeichnungssprache in die Datenbak packe. Attribute, die jedes Dokument/Seite/Artikel hat, kommen dann eben auch als solche in die Datenbank. Damit müssen nicht erst die Dokumente geparsed werden, um direkt auf diese Inhalte zugreifen zu können. (Hast du ja auch so geschrieben...)

Mitunter macht es auch Sinn, hier Infos redundant zu speichern. Wenn ein Text also z.B. einen Querlink enthält, dann macht es schon Sinn, die Existenz deses Links nochmal in die Datenbank zu packen, damit du mit einer einfachen Abfrage erfahren kannst, welche Seiten auf diese Seite verweisen. Das gleiche mit Bildern.

In aller Regel macht hier ein eigenes kleines Frontend (Formular) mehr Sinn, denn damit kannst du Zuordnungen schneller erfassen/eingeben und kannst direkt Rückmeldung über mögliche Fehler bekommen.

Ich würde mir in dem Kontext mal OpenOffice anschauen. Wäre ja fein, wenn du einfach nur eine odt-Datei über ein Web-Formular hochladen müsstest, dieses auf dem Server entpackt und analysiert wird und du dann nochmal ein Formular mit benötigten zusätzlichen Angaben in Abhängigkeit vom Dokument eben bekommst.

Gibt sicher auch fertige Klassen zur Analyse von odt-Dateien.

Ich meinte eine serverseitige Transformation mi XSLT. Wusste garnicht, dass es überhaupt schon Browser gibt, die XSLT beherrschen.

Da würd ich aber auch raten, nochmal anzuhalten und ggf. lieber bisher programmiertes nochal in die Tonne zu klopfen. Für mich hört sich das hier zumindest noch ziemlich roh an. Es steht ja noch nichtmal der Datenbank-Entwurf oder die Workflows. Solche Entscheidungen später nochmal neu zu treffen - mit anderem Ergebnis - kann teuer werden. Von daher würd ich mir hier erstmal eine gute Entscheidungsgrundlage schaffen, mich dann definitiv entscheiden und mögliche spätere Änderungen/Erweiterungen festhalten und dann erst loslegen. Natürlich ändert sich immer was an den Anforderungen im Entwicklungsprozess, aber ganz so schwammig loszulegen ist in jedem Fall ein krasses Risiko. Es sei denn, du bist so erfahren, dass du beim programmieren genau erkennst, welche Optionen du dir bei einer konkreten Implementierung dann eben gerade verbaust und dann eben an diesen Sellen anhalten kannst, um die entsprechenden Entscheidungen auf der Ebene der Anforderungen zu treffen.

Basti

PS:
Grad gelesen, dass MS in Zukunft auch das ODF unterstützt und wohl doch nicht sein eigenes XML-Süppchen kochen wird. Das ist doch mal was!