In einigen vorigen Beiträgen wurde auf den Primärschlüssel hingewiesen. Der ist in diesem Zusammenhang irrelevant.
Zitat:
gegeben ist folgende Tabelle:
Id Integer
PersonalId Integer
Datum Date
Uhrzeit Date
So wie es oben schon steht, suche ich eine Möglichkeit, zu verhindern,
dass zur gleichen PersonalId ein Eintrag mit gleicher PersonalId, Datum und Uhrzeit erzeugt wird
Es könnte also sein, daß Datensätze generiert werden (von wem auch immer), in denen PersonalID,Datum,Uhrzeit gleich sind. Diese Doubletten dürfen nicht gespeichert werden.
Also sollte die Auflösung der Uhrzeit so groß sein, daß doppelte Werte nicht möglich sind. Ist das nicht möglich, sollte eine Hilfskonstruktion wie z.B. ein Index-Feld (integer) für gleiche Datensätze verwendet werden. Oder aber es wäre zu Überlegen ob Uhrzeit überhaupt das richtige Unterscheidungskriterium wäre.
Der Primärschlüssel wird ja diskutiert, ob er geeignet ist das Ziel zu erreichen. Aber Deine Ausführungen streifen m.E. wie einige andere Beiträge einen Knackpunkt, der vielleicht bei der Auflösung hilft.
Der exakte, gewünschte Nutzen von Datum/Uhrzeit als sagen wir mal "Hilfsmittel" zur Eindeutigkeit ist eigentlich gar nicht klar:
Soll maximale Auflösung erreicht werden?
Oder soll im Gegenteil eine Beschränkung stattfinden?
Im ersten Fall komme ich selbst durch Kombination mit den anderen Schlüsselfeldern irgendwo an eine Grenze. Datum/Uhrzeit/Sekunden/Millisekungen* sind bei dem Datentyp beschränkt.
Im 2. Fall kann ich durch Beschneiden der Uhrzeit definieren, wie viel Datensätze es denn sein dürfen. Eine Kürzung des gespeicherten Wertes z.B. auf Sekunden würde ergeben, dass nicht mehr als 60 Werte pro Minute (in Kombination mit den anderen Schlüsselfeldern) gespeichert werden können.