Datenbankstruktur - wie speichern?

[jobo]

@scrat
Nach meiner bescheidenen Kenntnis, sind die virtuellen Punkte, die für Termine beim Arzt von den gesetzlichen Kassen angerechnet werden, oft recht bescheiden im Vergleich zur reinen Dauer des Termins. (Mal abgesehen von der nicht direkt zu beziffernden monetären Höhe dieser Punkte)
Die Termine würden also daran gemessen u.U. recht kurz und natürlich nicht gerastert ausfallen.

@p80286
Ja, erst mal ist es ein Timestamp als Datentyp. Taktung ist meinetwegen ok, aber sie führt so wie sie praktiziert wird und durch Software unterstützt wird ja offensichtlich mit (nicht allein) dazu, dass Arzttermine oft ein Glücksspiel sind- was die Wartezeit angeht.

Gedanken:
Das Raster ist virtuell und findet ohne vergebene Termine keine Ausprägung
Ein gegebenes Raster definiert sich (hier) dann durch (Stunden) Anteile, z.B.: 1, 2, 3, 4, 5, 6
Also umgerechnet volle Stunde, halbe -, 20 Minuten, 15 -, 12-, 10, -
Vorgabe wäre meinetwegen 20 Minuten als Standardaufteilung.
aber eigentlich egal, denn:
auf Stundenebene gilt die dann festgelegte Uhrzeit primär als Reihenfolge oder als konkrete Angabe von (kleineren) Intervallblöcken, ein Termin = 1-n explizite, exakt angegebene Intervalle
Das Ändern eines Rasters (als Ausnahme oder dauerhaft) wirkt sich nur bedingt auf bestehende Termine aus. Im einfachen Fall „kleineres Intervall“ wird „irgendwo“* innerhalb der Stunde ein weiterer Termin erfasst, im schwierigeren Fall „größeres Intervall“ fliegt ein Termin aus der Stunde raus. Beides sind natürlich Verschiebungen und man muss definieren, wie damit umgegangen werden soll.
a) bestehende Termine behalten einfach das alte Raster, nur neue Termine werden nach neuen Vorgaben vergebenen
b) „Reinquetschen“: aus Terminen 10:00 Uhr und 10:30 Uhr wird 10:00, 10:20, 10:40
c) „Strecken“: aus 10:00, 10:20, 10:40 wird 10:00 und 10:30, ein Termin braucht einen neuen Platz (manueller Vorgang, Absprache)
..
Für diese Fälle muss man entsprechende Update Statements bauen.

*Wahrscheinlich wäre ein „loses“ Modell -ganz ohne Raster- mit einigen Problemchen in der technischen Handhabung verbunden, auch wenn es ein paar Updates spart. (nicht notwendig im Sinne der Last)
Fall b) würde mit einem Insert zwischen bestehenden Terminen auskommen, wobei hinreichend wäre, dass die neue Terminzeit „irgendwo“ zwischen 2 bestehenden Terminen liegt. Die Anwendung muss die Rasterung grafisch sowieso variabel beherrschen, nur eben nicht abhängig von einer Grundeinstellung, sondern abhängig von der tatsächlichen Datenlage in der jeweiligen Stunde.

Denkbar für eine Rasterumstellung wäre ggf. auch, dass man sie nicht akut durchführt, sondern in der Zukunft, also ab einem Zeitpunkt x in 4 Monaten. Liegt er weit genug in der Zukunft (keine Termine vergeben oder wenige die man manuell neu vergibt), kann man wahrscheinlich mit einfacheren Verfahren operieren. Ändert aber auch nichts an der Speicherung als Timestamp.

Das ist m.E. alles eine Frage davon, welchen Aufwand der TE in die Änderung stecken will.

Die Ausführungen von @Moombas bringen eigentlich recht deutlich raus, wie es normalerweise laufen sollte. Die Rasterung ist eine reine Darstellungssache.