Speicherung Datumsformat

[Erik]

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

[matthias]

high,

als (datum)string: YYYY-MM-TT - also umgedreht - so kannst du sogar sortieren oder die phantastischen Datums- und Zeitfunktionen von MySQL nutzen: http://dev.mysql.com/doc/refman/4.0/de/date-and-time-functions.html

m.

[Erik]

Hallo matthias,

Huch, das ging aber schnell ... danke schonmal!

als (datum)string: YYYY-MM-TT - also umgedreht - so kannst du sogar sortieren oder die phantastischen Datums- und Zeitfunktionen von MySQL nutzen: http://dev.mysql.com/doc/refman/4.0/de/date-and-time-functions.html

Also im Prinzip 4) ... Das Format "[TT/][MM/]JJJJ" aus meinem Posting bezog sich nur auf das Format vom Benutzer bei der Eingabe, sorry für die Verwirrung.

Ja, das würde gehen, wäre aber nicht datenbank-unabhängig, oder?
Damit würde ich mich darauf verlassen, dass jede DB mit Datumswerten in String umgehen kann ... ich bin mir nicht sicher, ob das der Fall ist.
Mysql nimmt bei der Jahresangabe "1" das Jahr 2001 an. Die führenden Nullen müssten also immer gespeichert werden.

Bei Oracle ist mit to_char bzw to_date ne Menge machbar, ich hab bloß grad keine Oracle zum Testen da ... PG anyone?

MfG
Erik

[matthias]

Also im Prinzip 4) ... Das Format "[TT/][MM/]JJJJ" aus meinem Posting bezog sich nur auf das Format vom Benutzer bei der Eingabe, sorry für die Verwirrung.

ist ja egal wie du das bekommst aus dem formular. wenn du drei felder machst für tag, monat und jahr, baust du dir den string, der in die datenbank kommt, einfach neu zusammen.

klar kann der server keine gedanken lesen. wenn du also ein einfaches textinput fürs jahr anbietest, und jemand gibt ein: 77 - musst du das danach umwandeln in 1977, wenn 1977 gemeint ist ;) wenn jemand 1677 meint, weiß dein programm das nicht - womit die eingabe nicht vollständig ist...

wenn jemand einen monat mit 8 für august angibt, musst du logischerweise daraus ne zweistellige sache machen, mit führender null:

if(strlen($_POST["monat"])==1) {

$schreibemonat = "0".$_POST["monat"];

}

usw...

wenn du EIN input anbietest für ein format like: tt.mm.jjjj dann zerlege den string einfach und setze ihn neu zusammen... explode() eben...

wenn du unbedingt vor dem abschicken eine java-script-plausibilität haben willst:

array = variable.split(".") - und dann kannst du gucken, ob z.B. das jahr vierstellig ist...

ich würde aber mit php den string zusammenbauen und nicht mit der datenbank. sicher bietet mysql auch funktionen an, den string umzuwandeln. aber so ists am sichersten...

m.

[Erik]

Hallo!

ist ja egal wie du das bekommst aus dem formular.

Jep. Die letztendliche Implementation des Formulars dürfte einfach sein. Und auch die Zusammensetzung der Werte ... keine Sorge, ich bin kein Anfänger ;-)

MfG
Erik

[Ingo Turski]

Hi,

um sinnvoll mit Daten rechnen zu können, finde ich Zahlenwerte angebracht. Da Du auch weit in die Vergangenheit gehen willst, brauchst Du einen absoluten Nullpunkt: Christi Geburt bietet sich an.
Um die Werte leicht miteinander vergleichen zu können, mußt Du sie natürlich anhand eines bestimmten Kalenders umrechnen.

Was Du brauchst, ist a) eine Routine, die diese absoluten Zahlen anhand der Usereingaben errechnet (wobei Du auch durchaus verschiedene Kalender berücksichtigen kannst) und b) eine Routine, die aus diesen Zahlen wieder Tag, Monat und Jahr ermittelt.
Es gibt verschiedene mehr oder weniger komplexe Kalenderprogramme, die die Schaltjahre und andere Variablen berücksichtigt; mußt Du mal auf die Suche gehen.

Und wenn Du keinen Tag oder keinen Monat hast, ist die allgemein übliche Praxis, den Ersten zu nehmen.

Heraus kommen dann positive Tage, 0 für den 1.1.0000 und negative Tage, die Du sehr effizient miteinander vergleichen kannst.

freundliche Grüße
Ingo

[Erik]

Hallo Ingo,

danke für deine Antwort!

um sinnvoll mit Daten rechnen zu können, finde ich Zahlenwerte angebracht.

Jep, ich auch.

Da Du auch weit in die Vergangenheit gehen willst, brauchst Du einen absoluten Nullpunkt: Christi Geburt bietet sich an.
Um die Werte leicht miteinander vergleichen zu können, mußt Du sie
natürlich anhand eines bestimmten Kalenders umrechnen.

Wenn ich dich richtig verstanden habe, dann schlägst du vor, die Anzahl der Tage von einem Punkt (z.B. Christi Geburt) aus zu zählen.
<joke>Also quasi Unix-Timestamps in Tagen.</joke>

Ja, das ist sicher möglich.

Was Du brauchst, ist a) eine Routine, die diese absoluten Zahlen anhand der Usereingaben errechnet (wobei Du auch durchaus verschiedene Kalender berücksichtigen kannst) und b) eine Routine, die aus diesen Zahlen wieder Tag, Monat und Jahr ermittelt.
Es gibt verschiedene mehr oder weniger komplexe Kalenderprogramme, die die Schaltjahre und andere Variablen berücksichtigt; mußt Du mal auf die Suche gehen.

Gut, dann suche ich mal los ...

Ich will niemanden bewusste Fehler unterstellen ... aber:
Lass mich mal "den Advocatus Diaboli" spielen ... Wenn ein kleiner Fehler in der Routine sein sollte (gab da ein paar Sonderregeln in verschiedenen Kalendern), sind die Quelldaten nicht mehr viel wert ... und eine erneute Berechnung könnte zu weiteren Fehlern führen.

Und wenn Du keinen Tag oder keinen Monat hast, ist die allgemein übliche Praxis, den Ersten zu nehmen.

Ja, hab ich schon mal von gehört ... wie kann man dann aber einen "wirklichen Ersten" von einem "pseudo Ersten" unterscheiden?

MfG
Erik

[Ingo Turski]

Hi,

Wenn ich dich richtig verstanden habe, dann schlägst du vor, die Anzahl der Tage von einem Punkt (z.B. Christi Geburt) aus zu zählen.
<joke>Also quasi Unix-Timestamps in Tagen.</joke>

Genau - nur mit der Möglichkeit, auch negative Werte zu haben. Falls diese allerdings die Mehrheit darstellen, würde ich vielleicht den von Martin vorgeschlagenen "Nullpunkt" nehmen.

Ich will niemanden bewusste Fehler unterstellen ... aber:
Lass mich mal "den Advocatus Diaboli" spielen ... Wenn ein kleiner Fehler in der Routine sein sollte (gab da ein paar Sonderregeln in verschiedenen Kalendern), sind die Quelldaten nicht mehr viel wert ... und eine erneute Berechnung könnte zu weiteren Fehlern führen.

Das kannst Du so pauschal nicht sagen. Oft läßt sich eine falsche Berechnung wieder umkehren und die Ausgangswerte ermitteln.

Und wenn Du keinen Tag oder keinen Monat hast, ist die allgemein übliche Praxis, den Ersten zu nehmen.

Ja, hab ich schon mal von gehört ... wie kann man dann aber einen "wirklichen Ersten" von einem "pseudo Ersten" unterscheiden?

Musst Du das denn überhaupt? Wenn ja, setzt Du einfach ein Flag, wobei zwei Bit schon ausreichen.
Aus der Praxis kenne ich z.B. einige Volksgruppen, bei denen das Datum der Geburt nicht wie bei uns aktenkundig ist und auch kein Geburtstag gefeiert wird. Solche Personen bekommen dann vom Ausländeramt bei uns den 1.1. eingetragen. Statistisch gesehen sind dann also 99,7% dieser Einträge falsch - aber womit soll man sonst rechnen?

freundliche Grüße
Ingo

[Erik]

Hallo Ingo,

Ich will niemanden bewusste Fehler unterstellen ... aber:
Lass mich mal "den Advocatus Diaboli" spielen ... Wenn ein kleiner Fehler in der Routine sein sollte (gab da ein paar Sonderregeln in verschiedenen Kalendern), sind die Quelldaten nicht mehr viel wert ... und eine erneute Berechnung könnte zu weiteren Fehlern führen.
Das kannst Du so pauschal nicht sagen. Oft läßt sich eine falsche Berechnung wieder umkehren und die Ausgangswerte ermitteln.

Ja, es kommt immer auf die Situation an.

wie kann man dann aber einen "wirklichen Ersten" von einem "pseudo Ersten" unterscheiden?
Musst Du das denn überhaupt? Wenn ja, setzt Du einfach ein Flag, wobei zwei Bit schon ausreichen.

Naja, über "müssen" oder "sollten" bin ich mir noch nicht ganz sicher. Ich weiß bloß, dass es manchmal angebracht ist zu wissen, ob ein Datum eine exakte Angabe oder ein Nährungswert ist. Da muss ich also nochmal ein wenig nachdenken ;-)

Aus der Praxis kenne ich z.B. einige Volksgruppen, bei denen das Datum der Geburt nicht wie bei uns aktenkundig ist und auch kein Geburtstag gefeiert wird. Solche Personen bekommen dann vom Ausländeramt bei uns den 1.1. eingetragen. Statistisch gesehen sind dann also 99,7% dieser Einträge falsch - aber womit soll man sonst rechnen?

Ja - für eine Berechnung ist sowas dann wohl nötig (siehe Postings von/mit Martin).

MfG
Erik

[Johannes Zeller]

Hallo Erik,

Zusammengefasst willst du folgende Daten zu einem Datum speichern:

* Kalender (Julianisch, Gregorianisch, Chinesisch, Hebräisch, Islamisch, Maya, whatever)
* Genauigkeit des Datums (vor, nach, ca., genau, evtl. auch zwischen)
* Das Datum an sich (Tag, Monat, Jahr, Ära)

Die entsprechende Benutzereingabe würde ich so realisieren:
1. Die Angabe des Kalenders würde ich über ein Auswahlfeld machen, da das Programm mit Daten aus ihm unbekannten Kalendern wohl kaum rechnen kann ;-)
2. Auch für die Genauigkeit bietet sich natürlich eine Auswahlliste oder Checkboxen an.
3. Das ist das schwierige, da diese Angabe sehr vom verwendeten Kalender abhängt. Ära wäre beim Chinesischen oder Japanischen Kalender die Äranamen der Kaiser, beim Julianischen bzw. Gregorianischen Kalender v.Chr. oder n.Chr. und bei den Maya ist das Ganze wieder komplett anders.

Eine Möglichkeit zur Lösung des Problems wäre die Umrechnung aller Daten in einen gemeinsamen Kalender vor der Speicherung. Das wirft aber auch Probleme auf, wenn z.B. nur das Jahr im Islamischen Kalender bekannt ist. Wegen des unterschiedlichen Jahrensbeginns würde ein z.B. in den Gregorianischen Kalender umgerechnetes Datum vom der ursprünglichen Angabe abweichen.

Man könnte zwar auch das Datum als String in einem Kalenderspezifischen Format abspeichern, aber wie du selbst schon gesagt hast, wird dann das Rechnen und Abfragen der Daten sehr kompliziert.

Ich fürchte, dass es dafür kein Patentrezept gibt und du dir einen Kompromiss suchen musst, der bei deiner spezifischen Anwendung am wenigsten Probleme bereitet. Tut mir leid, wenn ich dir nicht helfen konnte.

Schöne Grüße,

Johannes

[Erik]

Hallo Johannes,

danke für deine Antwort!

Zusammengefasst willst du folgende Daten zu einem Datum speichern:

* Kalender (Julianisch, Gregorianisch, Chinesisch, Hebräisch, Islamisch, Maya, whatever)
* Genauigkeit des Datums (vor, nach, ca., genau, evtl. auch zwischen)
* Das Datum an sich (Tag, Monat, Jahr, Ära)

Ja, darauf wird es wohl hinauslaufen. Weniger eher nicht, denn regulär Fallback-Werte anzunehmen, läuft darauf hinaus, dass die Wartung/Ergebnis-Interpretation erschwert werden kann.

Die entsprechende Benutzereingabe würde ich so realisieren:

1. Die Angabe des Kalenders würde ich über ein Auswahlfeld machen, da das Programm mit Daten aus ihm unbekannten Kalendern wohl kaum rechnen kann ;-)
2. Auch für die Genauigkeit bietet sich natürlich eine Auswahlliste oder Checkboxen an.
3. Das ist das schwierige, da diese Angabe sehr vom verwendeten Kalender abhängt. Ära wäre beim Chinesischen oder Japanischen Kalender die Äranamen der Kaiser, beim Julianischen bzw. Gregorianischen Kalender v.Chr. oder n.Chr. und bei den Maya ist das Ganze wieder komplett anders.

Ja, dem stimme ich soweit auch zu.

Eine Möglichkeit zur Lösung des Problems wäre die Umrechnung aller Daten in einen gemeinsamen Kalender vor der Speicherung. Das wirft aber auch Probleme auf, wenn z.B. nur das Jahr im Islamischen Kalender bekannt ist. Wegen des unterschiedlichen Jahrensbeginns würde ein z.B. in den Gregorianischen Kalender umgerechnetes Datum vom der ursprünglichen Angabe abweichen.

Ja, das wäre dann der gleiche Effekt, wie ich es Ingo eben schrieb, schade eigentlich ... aber auch logisch. Unvollständige Daten erzeugen eben nicht 100% richtige Daten. Aber dann sollte man das auch direkt sehen können. Eine reine Jahresangabe ist in Ordnung, aber sobald detailiertere Daten angegeben sind, impliziert das auch eine gewisse Korrektheit und keine Schätzungen ... und ein "ca. 01.05.0008" sieht für mich komisch aus ... zumal bei den umgerechneten Werten ja die Quelldaten nicht mehr verfügbar wären.

Man könnte zwar auch das Datum als String in einem Kalenderspezifischen Format abspeichern, aber wie du selbst schon gesagt hast, wird dann das Rechnen und Abfragen der Daten sehr kompliziert.

Ja, leider. Sonst wäre das nämlich recht "schön".

Ich fürchte, dass es dafür kein Patentrezept gibt und du dir einen Kompromiss suchen musst, der bei deiner spezifischen Anwendung am wenigsten Probleme bereitet. Tut mir leid, wenn ich dir nicht helfen konnte.

Ach was, es hilft auch, wenn jemand mich darin bestätigt, dass gewisse Dinge so ohne weiteres nicht funktionieren. Die Lösung soll ja möglichst korrekt und robust werden ;-)

MfG
Erik

[Der Martin]

Hi Erik,

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.

ich würde bei dieser Aufgabenstellung auf jeden Fall das Datum in einem einheitlichen Format speichern, zusätzlich aber über ein Flag angeben, in welchem Kalender/Datumsformat das Datum ursprünglich vorlag. Das einheitliche Speicherformat sorgt dafür, dass du die Datumswerte leicht vergleichen, sortieren, oder gar Intervalle berechnen kannst.

Für mich würde sich als standardisiertes Speicherformat das Julianische Datum anbieten, das vor allem in der Astronomie verwendet wird. Es speichert die Anzahl der vergangenen Tage seit 4713 v.Chr. als Vorkommaanteil, die Uhrzeit (wenn man das nutzen möchte) als Nachkommaanteil. Dadurch ist die Berechnung von Zeiträumen sehr einfach, sogar den Wochentag kriegst du relativ einfach raus.

Natürlich bedeutet das auch, dass du eine Reihe von Umwandlungsfunktionen schreiben müsstest, also vom Julianischen zum Gregorianischen Kalender(westliche Welt), zum Jüdischen, zum Mohammedanischen, zum Chinesischen Kalender, etc. und jeweils zurück.

Im schlimmsten Fall hieße das, dass mehrere Geburtsdaten für eine Person richtig sein können.

Oder du bietest bei der Anzeige/Eingabe des Datums ein Auswahlfeld (select) oder Radiobuttons an, mit denen das Format ausgewählt wird. Dann kann der Anwender entscheiden, in welchem Datumsformat er den Eintrag sehen möchte. Defaultformat wäre sinnvollerweise dasjenige, in dem der Eintrag eingegeben wurde (daher das eingangs erwähnte Flag fürs Format).

Viel Spaß und Erfolg beim weiteren Brainstorming,
 Martin

[Erik]

Hallo Martin,

auch dir "danke" für deine Antwort.

Das mit dem Julianischen Datum klingt sehr interessant. Mir war bisher nicht bewusst, dass zwischen "Julianischen Datum" und "Julianischen Kalendar" ein solcher Unterschied besteht.

Bei allen Umrechnungen bleibt aber das Problem, dass die Eingabe-Daten unvollständig sein werden und dann die Schärfe der Information verloren gehen kann.
Eine Möglichkeit dem vorzubeugen, könnte es sein, das Julianische Datum zusätzlich zu den atomaren Werten des Datums und den Kalender-Daten zu speichern.
Dann könnten nährungsweise Vergleiche angestellt werden, und für eine Detailausgabe wäre der Ursprungswert noch vorhanden.
Nachteil: Bei Änderungen müssen alle Werte entsprechend geändert werden und es wiederspricht auch dem Grundsatz der Vermeidung von doppelten Daten.

Natürlich bedeutet das auch, dass du eine Reihe von Umwandlungsfunktionen schreiben müsstest, also vom Julianischen zum Gregorianischen Kalender(westliche Welt), zum Jüdischen, zum Mohammedanischen, zum Chinesischen Kalender, etc. und jeweils zurück.

Ja, aber es würde mich wundern, wenn sowas nicht bereits $mal gemacht  wurde. Ich werde kaum der erste sein, der sich darüber Gedanken macht ;-) ... Dann werd ich mal danach suchen.

Viel Spaß und Erfolg beim weiteren Brainstorming,

Danke ;-)

MfG
Erik

[Daniel Thoma]

Hallo Erik,

Eine Möglichkeit dem vorzubeugen, könnte es sein, das Julianische Datum zusätzlich zu den atomaren Werten des Datums und den Kalender-Daten zu speichern.

Ich würde wohl sowas machen. Das würde auch Dein Problem lösen, was passiert, wenn Du Fehler bei der Umrechnung machst. Das Geburts- und Totesdatum von Menschen ändert sich nicht so oft, von daher kann man damit Leben, dass das Datenbankdesign in dem Fall nicht ganz normalisiert ist.

Alternativ könntest Du natürlich die Umwandlungsprozedur als Stored Procedure in die Datenbank packen und z.B. ein View anlegen, der das berechnete Datum enthält. Dann kannst Du mit dem einheitlichen Datum rechnen, ohne es fest zu speichern. Nachteile dieser Lösung sind höhere Anforderungen an die Fähigkeiten der Datenbank und ein höherer Berechnungsaufwand. Aber auch das stellt vermutlich kein Problem dar.

Grüße

Daniel

[Erik]

Hallo Daniel,

auch Dir "Danke" für deine Antwort.

Ich würde wohl sowas machen. Das würde auch Dein Problem lösen, was passiert, wenn Du Fehler bei der Umrechnung machst. Das Geburts- und Totesdatum von Menschen ändert sich nicht so oft, von daher kann man damit Leben, dass das Datenbankdesign in dem Fall nicht ganz normalisiert ist.

Ja, das sehe ich inzwischen auch so. Die Normalisierung soll ja dabei helfen, die Fehler/Komplexität von Datenstrukturen zu verbessern und nicht das Gegenteil.

Alternativ könntest Du natürlich die Umwandlungsprozedur als Stored Procedure in die Datenbank packen und z.B. ein View anlegen, der das berechnete Datum enthält. Dann kannst Du mit dem einheitlichen Datum rechnen, ohne es fest zu speichern. Nachteile dieser Lösung sind höhere Anforderungen an die Fähigkeiten der Datenbank und ein höherer Berechnungsaufwand. Aber auch das stellt vermutlich kein Problem dar.

Ja, das Szenario ruft förmlich danach ... leider kann nicht jede DB, die ich unterstützen möchte, mit SP und Views umgehen.

MfG
Erik