Kritik Tabellenstruktur

[Vinzenz Mai]

Hallo,

das hört sich schon einmal gut an. Noch besser wäre es gewesen, wenn Du Deine Tabellenstruktur gepostet hättest.

Die Namensgebung (und vielleicht auch die Darstellung) ist etwas komisch, aber ich hoffe trotzdem, dass folgendes verständlich ist:

verständlich ja, aber auch kritikwürdig. Sei doch bitte konsistent und
verwende entweder komplett englische oder deutsche Bezeichnungen, so ein
Mischmasch mutet stets etwas seltsam an.

Tabelle: blogentry

blogentries böte sich an, Du willst ja mehr als einen speichern :-)

* ID INT AUTO_INCREMENT PRIMARY KEY,

Das Primärschlüsselfeld _id_entifiziert jeden einzelnen Datensatz, deswegen
sind künstliche Schlüssel so beliebt, deswegen enthalten Primärschlüsselfelder
gern die Zeichenfolge id. Es ist eine gute Idee, das Feld so zu benennen, dass
man auch erkennt, was dieses Feld identifiziert, z.B. blogentry_id oder
id_blogentry, je nach Konvention, die man sich selbst setzt.

* IP VARCHAR(20),

Warum 20? Willst Du IPv6-Adressen speichern? In dotted-decimal
(gepunktet-dezimaler klingt bemüht) Darstellung benötigst Du maximal
15 Zeichen. Wenn Du irgendwann auf IPv6 aufrüstest, würde ich dafür
eine eigene Spalte nehmen.

* datum VARCHAR(20),

Das ist, mit Verlaub, gar keine gute Idee. Nimm einen der Datumstypen des
Datenbankmanagementsystems, siehe MySQL-Handbuch, Datums- und Zeittypen.

In diesem speziellen Fall könntest Du den Datentyp TIMESTAMP verwenden, der
nichts mit UNIX-Timestamps zu tun hat, aber z.B. den Zauber mitbringen kann,
dass der Wert beim INSERT automagisch gesetzt wird, ohne dass Du Dich darum
kümmern musst.

Den großen Vorteil, den Dir die Datumstypen Deines DBMS bieten, sind die
Sortierung und die Vielfalt an Datums- und Zeitfunktionen, die Du sofort
nutzen kannst. Sonst musst Du immer zuerst eine Konvertierung vornehmen,
die erstens unnötig ist und zweitens Performance kostet. MySQL bietet genug
Funktionen, um bei der Abfrage der Daten die Zeitangabe nach Deinem Geschmack
zu formatieren.

* kategorie VARCHAR(255),

Soviele Kategorien wirst Du wohl nicht haben, sie werden sich auch selten
ändern. Hier böte sich der Datentyp ENUM an, siehe auch in der aktuellen
Forumshauptdatei im Thread https://forum.selfhtml.org/?t=151183&m=983039.

* titel VARCHAR(200) UNIQUE,

Das ist ja in Ordnung, dass die Titel eindeutig sein müssen, es ist aber ...

* autor VARCHAR(255),
    * url VARCHAR(255),
    * inhalt TEXT

Tabelle: comments
    * ID INT AUTO_INCREMENT PRIMARY KEY,
    * IP VARCHAR(20),
    * name VARCHAR(200),
    * entry VARCHAR(200),                <- Speichert den Titel des Eintrages, auf den er sich bezieht.

... keine gute Idee, die Verknüpfung über den Titel zu realisieren. Nimm die
ID aus der Tabelle blogentry. Und noch etwas: Dieses Fremdschlüsselfeld ist
mit einem Index zu versehen.

Selbstverständlich darf dieser Index nicht UNIQUE sein, Du willst ja mehr als
einen Kommentar zu jedem Blogeintrag zulassen.

* email VARCHAR(200),
    * url VARCHAR(200),
    * datum VARCHAR(20),
    * inhalt TEXT,

Wenn Du als Storage Engine InnoDB verwendest, dann kannst Du außerdem mit
FOREIGN-KEY-Constraints arbeiten, siehe Handbuch. Somit sicherst Du auf
Datenbankebene gegen fehlerhafte Einträge, d.h. gegen Kommentare zu
Blogeinträgen, die nicht existieren.

ON DELETE CASCADE kann dafür sorgen, dass beim Löschen eines Blogeintrages
(aus welchem Grund auch immer) automagisch alle zugehörigen Kommentare gelöscht
werden, ohne dass Du Dich selbst darum kümmern musst.

Freundliche Grüße

Vinzenz