Ich hab im Studium nun im 2. Semester endlich Fächer bekommen wie Datenbanken und Algorithmen.

Auch wenn ich mit Datenbanken schon mehr als 3 Jahre teils sehr aktiv arbeite, war ich doch stark überrascht, was mir versucht wurde beizubringen.
Die fachliche Kompetenz der Professorin möchte ich nicht in Frage stellen, allerdings muss ich die Praxisnähe, die eigentlich ein Vorteil einer Fachhochschule sein sollte, anzweifeln.

Warum ich das mache? Schauen wir uns einmal das Relationshipmodel an, das mit der Dokumentation zur ersten Datenbank mitgeliefert wurde:

Was auf den ersten Blick sofort auffallen sollte:
Kryptische Abkürzungen von Tabellen- und Spaltennamen. Das fordert jeden, der diese Datenbank nicht kennt aber verwenden will, dass er sich durch eine Dokumentation liest, nur um zu wissen, was zum Beispiel MGEHT oder LS_DATUM oder VPREIS sein soll.
Hätte man diese Spalten Mengeneinheit (MGEHT), Lieferscheindatum (LS_DATUM) und Verkaufspreis (VPREIS) genannt, wäre schonmal die Optik und das intuitive Verständnis besser.

Damit ist aber nicht genug.
Schauen wir einmal tiefer, dann sehen wir zum Beispiel die Tabellendefinition der Artikelstammdaten an:
(Zeilennummern sind in Klammern davorgeschrieben)
(01) CREATE TABLE IF NOT EXISTS `artst` (
(02) `artnr` varchar(5) NOT NULL,
(03) `artbez` varchar(25) default NULL,
(04) `ekpreis` int(11) default NULL,
(05) `vpreis` int(11) default NULL,
(06) `mgeht` varchar(5) default NULL,
(07) `gruppe` varchar(2) default NULL,
(08) `kw` int(11) default NULL,
(09) `bestand` int(11) default NULL,
(10) PRIMARY KEY (`artnr`),
(11) KEY `gruppe` (`gruppe`)
(12) ) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Lasst mich das mal Zeile für Zeile durchgehen:
Zeile 01:
CREATE mit IF NOT EXISTS, dagegen kann man nichts sagen, aber warum ARTST? Artikelstamm oder kürzer Artikel wäre besser gewesen.

Zeile 02:
Wie wir in Zeile 10 sehen, soll ARTNR der Primärschlüssel sein. Doch warum ist das ganze dann bitte ein VARCHAR(5)? VARCHAR als Datentyp für Schlüssel ist vielleicht bei Hash-Werten oder ISBN-Nummern sinnvoll, allerdings nicht, wenn die Schlüssel normale Zahlenwerte sind, die eigentlich auch noch ein AUTO_INCREMENT gebrauchen könnten.
Meiner Meinung nach sollte hier ID als Spaltenname gewählt sein und der Datentyp INT(11).

Zeile 03:
ARTBEZ ist wohl der Artikelname bzw die Bezeichnung. Wenn die Tabelle schon darauf deutet, dass es sich bei den Datensätzen in der Tabelle um Artikel handelt, warum nochmal die Spalte mit “Art” versehen? Eine Bezeichnung für eine tropische Krankheit wird dort sicher nicht gespeichert…
Der Datentyp VARCHAR(25) ist ok dafür.

Zeile 04:
EKPREIS… wieder eine herrliche Verstümmelung. Einkaufspreis wäre besser! Warum allerdings ein INT und kein DOUBLE Verwendung findet, ist für mich nicht verständlich. Preise und Währungen haben nunmal Kommastellen.

Zeile 05:
VPREIS… jetzt wirds kurios: Wenn Einkaufspreis EKPREIS ist, warum ist dann Verkaufspreis nur VPREIS? Es wurde also selbst bei der Verstümmelung keine durchgängige Syntax verwendet. Datentyp ist genauso unverständlich wie bei Zeile 04.

Zeile 06:
MGEHT… wie MGEHT eine Abkürzung für Mengeneinheit sein soll, ist für mich auch nach 3 Wochen mit dieser Datenbank ein unverständliches Phänomen. Datentyp scheint mit VARCHAR(5) ok zu sein. Wörter wie Stück und Meter passen rein.

Zeile 07:
GRUPPE… ist ein Fremdschlüssel zur Tabelle ARTGRU (Siehe auch Zeile 11). Auch hier muss man sich erstmal fragen, warum hier z.B. nicht artikelgruppe_id als Spaltenname verwendet wird (es gibt auch Kundengruppen, deswegen sollte der Bezeichner eindeutiger sein als nur gruppe_id). Als zweites ist der Datentyp mit VARCHAR(2) alles andere als geeignet für einen Schlüssel. (Siehe dazu auch Bemerkung zu Zeile 02).

Zeile 08:
KW steht für Kalenderwoche. Warum auch immer das nicht dann auch Kalenderwoche heisst… Abgesehen davon ist eine Kalenderwoche mit INT(2) voll und ganz bedient. INT(11) ist unnötigerweise zu groß.

Zeile 09:
Bestand… endlich mal eine Spalte, bei der man nichts falsch gemacht hat.

Zeile 10 - 12:
Primary Key und Foreign Key sind definiert und die Engine ist sogar InnoDB und unterstützt damit Transaktionen. Da bleibt nur die Frage, warum nicht UTF-8 verwendet wurde.

Fazit:
Im großen und ganzen sind die beiden Datenbanken, die ich bisher gesehen habe einfach nur unpraktikabel. Letztes Beispiel: Datenbank “company” hat folgende Tabellennamen: D, E, S, P, J, SP, SPJ…