Namenstage in DB speichern

Don Jan 9 14:56:31 CET 2003

Hi Andy,

Am 8 Jan 2003 um 17:40 hat Andreas Stagl geschrieben:

> Dabei ist mir aufgefallen, dass ich den Jahr-Bereich des DATE Datentyps 
> eigentlich garnicht bräuchte (derzeit füll ich diesen Bereich mit 2004 
> auf... 2004 deshalb, weil 2004 ein Schaltjahr ist und ich somit einen 29 
> Februar zur Verfügung hab).
> Deshalb wollte ich hier fragen, ob ich den DATE Datentyp noch irgendwie 
> optimieren kann, sodass kein Jahr mitgespeichert wird (ich aber trotzdem 
> einen 29 Februar zur Verfügung hab). Falls dies nicht geht... wäre es 
> sinnvoll, anstatt des DATE Datentyps einen CHAR Datentyp zu nehmen und das 
> Datum dann eben in der  Form MMTT als String abzuspeichern oder würdet ihr 
> eher davon abraten?

Eine Datumsfunktion zum Speichern der Tage ohne Jahr gibt's leider 
nicht. Alternative: CHAR - ist aber auch blöde, denn die 
Datumsfunktionen von MySQL sind n ziemlicher Hammer; wäre schade, 
wenn Du die in einer kalenderähnlichen Struktur nicht anwenden 
könntest.

Ein Beispiel wäre, den nächsten Namenstag anzuzeigen, der ausgehend 
vom aktuellen Datum ansteht:

Die Alternative zu den MySQL-Funktionen ist natürlich eine handliche 
Middleware, mit der Du das auch ganz prima erledigen kannst, wenn Du 
einen CHAR-Vergleich machst. Obiges Bsp für PHP:

$heute = date(m) . "-" . date(d);
Als SQL musst Du in Deiner Struktur dann folgendes absetzen:
SELECT datum, vorname FROM namenstage
      WHERE datum > $heute
      ORDER BY datum ASC
      LIMIT 0,1;

Nu kann man sich streiten, was sinnvoller ist. Klar ist die reine 
MySQL-Variante [komplettes Datum und MySQL-Funktionen] performanter - 
aber bleiben wir doch mal auf dem Teppich: Es steht zu erwarten, dass 
Deine Tabelle maximal 366 Tupel mit je schätzungsweise 30 Byte 
enthalten wird. [10 für Datum [komplett] und 20 für den Namen]. Das 
macht ungefähr 10.7 kByte [für die ganze Tabelle!!!] Einen Index 
brauchste dabei ja wohl auch eher nicht.

Bei 10,7 kByte würd ich keine großen Performancesprünge erwarten, 
wenn Du das mit der grottigsten Middleware bediente 
schlechtestmögliche DB-Design mit einer hochgradig optimierten Lösung 
vergleichst.

Fazit: Meiner Meinung nach ist das reine Geschmackssache, welche 
Lösungsvariante Du wählst. Ich persönlich würde jedoch die Version 
mit dem kompletten Datum vorziehen - wegen der sauberen 
Implementierung! Das Jahr musste ja nicht berücksichtigen ;-))

Übrigens: Wenn Du ein Datum in MySQL einträgst musst Du nicht darauf 
achten, dass es ein Schaltjahr ist, wenn Du den 29.02. vermerken 
willst. MySQL prüft nur, ob das Datum plausibel ist, d.h ob
  0 < Tag < 32   und
  0 < Monat < 13 und 
  [ beim Jahr hab ich die Grenzen jetzt nicht im Kopf! ]

Demnach kannst Du problemlos den 29.02.2001 oder den auch den 
30.02.2002 eintragen. Willst Du gleich beim Eintragen prüfen, ob das 
Datum überhaupt existiert - und da sind wir schon bei den MySQL-
Datumsfunktionen - musst Du beim Eintragen gleich noch ein
DateADD ausführen, bei dem Du zu dem Datum 0 Tage addierst. Dann 
prüft MySQL tatsächlich auch, ob das Datum überhaupt existiert.

Manche Funktionen sind in MySQL halt ein wenig versteckt oder anders 
ausgedrückt: eingebaut aber nicht sofort zu sehen.  ;-))

Viele Grüße

Enrico Ortmann
[ortmann at onlineagentur-acon.com]
--------------------------------------------------------
ACON Onlineagentur & Multimedia
Dorfstr. 34 // 16348 Ruhlsdorf
Fon/Fax: +49-33305-71236/-71237
http://www.onlineagentur-acon.com

-- 
Infos zur Mailingliste, zur Teilnahme und zum An- und Abmelden unter
-->>  http://www.4t2.com/mysql 

Mailinglisten-Archive

Namenstage in DB speichern