Datenbank-Design

[Tom]

Hello,

Selbstverständlich ist die Zeit (bzw die Slot-Kennung) ein Schlüsselbestandteil.
Und zwar, wie schon erwähnt, in den Unique-Kombinationsschlüsseln (A-Z) und (B-Z).

ein Unique-feld muss nicht zwangsweise auch bestandteil eines schlüssels sein,

Jedes Feld, das in einen Index aufgenommen wird, ist auch Bestandteil eines Schlüssels, nämlich des des Index. Über den Index (auch Schlüssel genannt) kann man die Datensätze auffinden. Wenn dieser Index primär ist, identifiziert er auch den Datensatz.

Dies hier ist übrigens ein gutes Beispiel dafür, dass ein Unique Key nicht auch gleichzeitig ein (gültiger) Primärschlüssel sein muss, und dass ein Datensatz sogar drei Unique Keys haben kann. Er sollte aber (nach gültiger Regel) neu _einen_ Primärschlüssel haben.

Der Unterschied zwischen den beiden (Unique Key und Primary Key) ist die Bindung an die Daten. Ein Primary Key hat eine unbedingte _Bindung_ an den Datensatz, ist aber niemals selber Bestandteil der Daten des Datensatzes. Unsere drei Schlüssel hier sind aber Bestandteil der Daten.

zumal der auch noch das kriterium not null erfüllt. ein schlüssel dient nur dazu, einen datensatz eindeutig zu identifizieren

Nein. Ein Schlüssel muss nicht primär sein.

und dazu braucht man die zeit in diesem falle nicht. es müsste nur teil des keys sein, falls die gleichen austeller/besucher mehrere termine ausmachen. ansonsten würde die aussteller/besucher id ausreichen oder aber ein künstlicher schlüssel. auch wenn die zeit unique ist, so ist sie doch nur ein attribut.

Diesen Absatz versteh ich jetzt nicht. Bahnhof?

[...]

das mag so sein, ist aber trotzdem kein argument für einen schlüssel. desweiteren würde dazu eine zeitangabe nicht reichen, sondern man bräuchte einen start und endzeiptunkt. schließlich macht es wenig sinn, wenn man jede sekunde einen neuen termin haben kann.

Wenn Du doch wenigstens gelesen hättest, was ich geschrieben habe...

Die Spalte Z ist die Slotkennung in der vorgesehenen Quantisierung. Darum kommst Du nicht drum herum, wenn das System nicht zu kompliziert werden soll. Alternative wären zwei Spalten (von und  bis), um den gebuchten Terminbereich zu kennzeichnen.

Der lässt sich aber mMn nicht durch einen einfachen Nachschlage-Index (einer der auf statische Datenbestandteile geht) abfangen, sondern würde einen berechneten benöten. Den unterstützt aber MySQL nicht, oder?

Harzliche Grüße aus http://www.annerschbarrich.de

Tom