Trotz der ganzen schönen MySQL Befehle die man mal in P3 gehört hat, fehlte - mir zumindest - auch ein praktischer Teil, um mir irgendwas zu merken. Sein es nun die Befehle oder allgemeine Konzepte. Ohne Anwendung verschwindet so etwas nach spätestens zwei Monaten aus meinem Hirn.

Und nun stehe ich hier und frage mich, wie ich mein Textdatei-Datenbank-Gewirr vernünftig in MySQL umbastell. Datenbanken anlegen und Daten mit Perl auslesen ist ja denkbar einfach, aber bei der Struktur bin ich mir total unschlüssig.

Im Prinzip habe ich eine Anhäufung von Essays. Diese haben dann noch als Zusatzinfos Kategorie, Titel, Autor, Bilder, … Zu allen Essays kann man Kommentare schreiben, die dann mit Timestamp und Autor versehen werden.

Meine erste Idee wäre es zwei Tabellen anzulegen. Einmal halt für die Essays und eine für alle Kommentare. Den Text der Essays würde ich ebenfalls mit in die Datenbank klatschen. So weit okay?

Dann würde ich auch noch immer wenn ein Kommentar abgegeben wird, die Zahl inkrementieren, welche in der ersten Datenbank gespeichert ist, um diese Zahl schneller verfügbar zu haben (auf der Startseite werden mehrere Essays untereinander angezeigt und darunter steht dann so ein typisches Kommentare (#)). Oder ist das bei der Geschwindigkeit von MySQL eher angebrachter, einfach aus der zweiten Tabelle die Zahl der treffenden Kommentare auszulesen?

Letztlich kam mir dann noch die Frage, wie ich das mit den beigefügten Bildern handhabe. Das können 0 bis x sein. Wegen der variablen Zahl würde ich in der Tabelle einfach ein Textfeld nehmen und hier mit einem festgelegten Trennzeichen die Bildernamen hintereinander schreiben und mir später in Perl auseinanderfrimeln lassen. Unschönes vorgehen? Wie sonst?

Also grundsätzlich würde ich das ganze auch so aufbauen.

Eine Essay-Tabelle mit primary id (kann mysql automatisch inkrementieren) Titel, Autor, …

Eine zweite Tabelle mit den Kommentaren (Name, .. etc, und id des essay!)

Insgesamt kann ich aus meinen MySQL Projekten sagen, dass ich bisher keine Probleme hatte Einträge von MySQL zählen zu lassen (bis ca. 10.000 Einträge getestet), also einfach mit etwas wie SELECT COUNT(*) AS anzahl FROM tabelle WHERE bedingung = '..'

Zu den Bildern, das ist vielleicht nicht die schönste Methode, aber praktisch sicher ausreichend. Wenn man die Bilder untereinander mehrfach verwendet, dann wäre evtl. auch eine Bilder-Tabelle gut und eine Tabelle für die Verknüpfungen bzw. Relationen, welche Bilder(-IDs) zu welchem Essay(-ID) gehören.

Super, danke dir. Dann werde ich gleich mal loswerkeln.

Ach ja, was noch ein großer Nachteil ist, wenn man eine Eigenlösung benutzt wie beispielsweise Bilder mit Komma getrennt in einem Feld, ist, dass wenn man später das ganze ausbauen möchte, in dem Beispiel z.B. auch Kommentare zu Bildern anbieten möchte, dass man dann da irgendwie drumherum basteln muss oder doch wieder alles zerlegen, das kann teilweise nervig werden ;)

Edit: Mist, da war jemand schneller. Also als Wiederholung:

Meine erste Idee wäre es zwei Tabellen anzulegen. Einmal halt für die Essays und eine für alle Kommentare. Den Text der Essays würde ich ebenfalls mit in die Datenbank klatschen. So weit okay?

Klingt gut.

Dann würde ich auch noch immer wenn ein Kommentar abgegeben wird, die Zahl inkrementieren, welche in der ersten Datenbank gespeichert ist, um diese Zahl schneller verfügbar zu haben (auf der Startseite werden mehrere Essays untereinander angezeigt und darunter steht dann so ein typisches Kommentare (#)). Oder ist das bei der Geschwindigkeit von MySQL eher angebrachter, einfach aus der zweiten Tabelle die Zahl der treffenden Kommentare auszulesen?

Da würde ich tatsächlich lieber einen "select count(kommentar) from kommentare where essay = 'bla'" verwenden. Im Zweifel kannst Du noch einen Index für das kommentar-Feld anlegen. Dann sollte das auch bei ein paar tausend Einträgen immer noch in unter einer Sekunde ablaufen.

Letztlich kam mir dann noch die Frage, wie ich das mit den beigefügten Bildern handhabe. Das können 0 bis x sein. Wegen der variablen Zahl würde ich in der Tabelle einfach ein Textfeld nehmen und hier mit einem festgelegten Trennzeichen die Bildernamen hintereinander schreiben und mir später in Perl auseinanderfrimeln lassen. Unschönes vorgehen? Wie sonst?

Kommt drauf an, was das für Bilder genau sind. Sind diese im Text an festen Postitionen vorhanden (sprich bspw. per HTML-Tag eingebunden)? Dann musst Du sie garnicht in der DB ablegen, sondern nur im Filesystem. Sollen das hingegen Bilder sein, die irgendwie zu dem Essay passen, dann erscheint es mir sinnvoll die Positionen im Filesystem in die DB mit aufzunehmen. Hier wäre dann noch interessant, ob ein Bild auch mal zu zwei Essays gehören kann und die Frage, ob Du so etwas wie Namen, Beschreibungen oder Datum des Bildes mit erfassen möchtest? Solltest Du tatsächlich nur eine lose Sammlung von Bildern ohne Zusatzangaben wollen, dann reicht ein Textfeld mit eindeutig getrennten Einträgen völlig aus. Solltest Du ein wenig darüber hinaus wollen, würde ich die Bilder in eine dritte Tabelle packen.

Gruß Hanno

Buchempfehlung ist der Melton:

SQL:1999 : understanding relational language components / Jim Melton; Alan R. Simon

(Aus dem Infbib Katalog)

Also ich würde für die Bilder auf keinen Fall die Komma-Lösung verwenden. Das widerspricht ja total dem Prinzip der relationalen Datenbanken, dass man nur atomare Daten speichert. Stichwort: 1. Normalform!

Hmm. Hmm. Ich glaube ich lasse es bei einen Hauptbild und Kennzeichne die Bilder beim Upload einfach entsprechend der Topic ID, bzw. lasse die dann als Galerie später aus dem Filesystem einfach von Perl auslesen.