Erik: Speicherung Datumsformat

Beitrag lesen

Hallo zusammen,

"Programmiertechnik" trifft es noch am besten, es ist aber eher ein Entwurf-Brainstorming ...
Die endgültige Umsetzung soll mittels PHP5 und einer relationalen DB (soll weitgehend unabhängig von der DB funktionieren) passieren.

Ich möchte eine Personendatenbank erstellen, also (vereinfacht) Vorname, Nachname, Geburts- und Todesdatum & Co. Bis hierher klingt es einfach ;-) (und ist es auch).

Ein wenig Kopfzerbrechen machen mir die Datumswerte. Denn in dieser DB sollen nicht nur lebende, sondern auch bereits gestorbene Personen erfasst werden können. Sprich: Personen, die vor einem, tausend, zweitausend oder dreitausend Jahren gelebt haben oder leben.
Desweiteren kommt noch hinzu, dass ich mit den Datumswerten rechnen will. Ich möchte also sagen können, wann eine Person geboren wurde oder gestorben ist.
Eine häufige Abfrage wird sein, welche Personen schon eine bestimmte Zeit (z.B. 70 Jahre) lang tot sind.
Um das Ganze zu verkomplizieren, sind jeweils nicht alle Daten eines Datums bekannt. Von manchen Personen ist nur z.B. bekannt, dass sie im Jahre 300 v.Chr. geboren wurden, aber nicht, an welchem Tag oder gar Monat.

Zusätzlich kann es ja auch vorkommen, dass unterschiedliche Kalender zum Einsatz kommen ... sprich: im asiatischen Raum gibt es eine andere Zeitrechnung als im europäischen Raum. Eine einheitliche Behandlung würde voraussetzen, dass alle Daten in einen Kalender umgerechnet werden (ok, damit kann ich leben) oder aber eine Angabe zum verwendeten Kalender gespeichert wird. Im schlimmsten Fall hieße das, dass mehrere Geburtsdaten für eine Person richtig sein können.

Es gibt verschiedene Möglichkeiten, ein Datum zu speichern.

  1. Unix-Timestamp
    Fällt (natürlich) komplett raus, weil damit keine Daten vor 1970 erfasst werden können (wenn das Programm plattformübergreifend arbeiten soll).

  2. DATE/DATETIME (=mysql, gibt ähnliche Datentypen bei anderen DBs)
    Fällt auch raus, da damit keine Daten vor Christi Geburt als valide erkannt werden (können). Es ist zwar möglich, eine Art Vorzeichen in einem weiteren Feld zu speichern, aber dennoch werden die Daten beim Eintrag (z.B. mysql) als ungültig erkannt. Und es könnten keine partiellen Daten eingegeben werden (z.B. wenn nur Jahreszahl bekannt ist).

  3. Freitext pur
    Damit kann nur schwer gerechnet werden und das Format muss verhältnismäßig aufwenig erkannt/sichergestellt werden. Dadurch wird die Eingabe unnötig benutzunfreundlich. Speicherung als Textwert (im Sinne von varchar).
    Fällt aus auch eher raus.

  4. Pseudo-Freitext Variante 1
    Der Benutzer bekommt ein Beispiel vorgegeben, wie das einzugebende Datum aussehen soll; z.B. [TT/][MM/]JJJJ durch entsprechende Input-Felder unterstützt. Weiterhin muss er (z.B. durch Checkboxen) den verwendeten Kalender, sowie ggfs ein "[v|n].Chr." angeben. Speicherung als Textwert (im Sinne von varchar).
    Nachteil: Rechenoperationen sind schwierig und Ergebnisse müssten über eine Like-Suche ausgewählt werden.

  5. Pseudo-Freitext Variante 2
    Wie 4), mit dem Unterschied, dass das Datum in atomare Werte aufgesplittet wird und in verschiedenen Feldern gespeichert wird.
    Nachteil: um Normalisierung gerecht zu werden, ist wohl eine weitere Tabelle nötig. In etwa mit folgenden Feldern:
    id | fk_person_id | datum_art (Geburt|Tod) | tag | monat | jahr | fk_kalender_id | before_christ_flag
    (Ok, tolle Normalisierung ist was anderes ... )
    Vorteil: Die Datentypen der jeweiligen DB können benutzt werden, Like-Suche nicht mehr nötig (Performance-Steigerung).

Ok, meine Fragen:
a) Gibt es andere Möglichkeiten? Habe ich was übersehen?
b) Denkfehler in den aufgezählten Möglichkeiten?
c) Mein Favorit ist 5) ... wie schauts bei dir aus?

Wer es bis hierhin geschafft hat, hat schon mal meinen Dank, über eine Antwort würde ich mich noch mehr freuen :)

MfG
Erik