Sven: MySQL: Sinnvoller Datentyp für Feld mit Monat und Tag?

Hallo.

Wie im Betreff stehend, suche ich einen sinnvollen Datentyp für Werte, die ausschließlich aus dem Monat und Tag bestehen. DATE und DATETIME sind ja irgendwie nicht wirklich passend. Da ich möglicherweise aber auch Datums- und Zeitfunktionen auf diese Felder anwenden will irgendwann, möchte ich auch keinen INTEGER- oder VARCHAR-Datentyp verwenden.
Hat da jemand vielleicht eine Idee? Oder übersehe ich vielleicht irgendwas naheliegendes?

Danke im Voraus schonmal :)

  1. Was bleibt denn dann noch übrig ?  ^^

    Ich verwende:
    int (10) timestamp rein und damit sollte man doch eigentlich alles anzeigen und bearbeiten können.

  2. Hallo.

    Wie im Betreff stehend, suche ich einen sinnvollen Datentyp für Werte, die ausschließlich aus dem Monat und Tag bestehen. DATE und DATETIME sind ja irgendwie nicht wirklich passend. Da ich möglicherweise aber auch Datums- und Zeitfunktionen auf diese Felder anwenden will irgendwann, möchte ich auch keinen INTEGER- oder VARCHAR-Datentyp verwenden.
    Hat da jemand vielleicht eine Idee? Oder übersehe ich vielleicht irgendwas naheliegendes?

    Bei dem was Du alles ausschließt, bleibt nicht mehr viel übrig außer blob, enum und text.

    Hotte

  3. echo $begrüßung;

    Wie im Betreff stehend, suche ich einen sinnvollen Datentyp für Werte, die ausschließlich aus dem Monat und Tag bestehen. DATE und DATETIME sind ja irgendwie nicht wirklich passend. Da ich möglicherweise aber auch Datums- und Zeitfunktionen auf diese Felder anwenden will irgendwann, möchte ich auch keinen INTEGER- oder VARCHAR-Datentyp verwenden.
    Hat da jemand vielleicht eine Idee? Oder übersehe ich vielleicht irgendwas naheliegendes?

    Valide Werte für die Kombination von Monat und Tag sind abhängig vom Jahr. Ohne eine Jahresangabe lässt sich nur schwer damit rechnen. Du musst dann eigenen Regeln erstellen und kannst weniger auf die vorhandenen Funktionen zugreifen. Es reicht dann auch, (TINY)INT zu verwenden.

    echo "$verabschiedung $name";

  4. yo,

    Da ich möglicherweise aber auch Datums- und Zeitfunktionen auf diese Felder anwenden will irgendwann, möchte ich auch keinen INTEGER- oder VARCHAR-Datentyp verwenden.

    nimm Date und fülle das jahr mit einem festen wert wie zum beispiel 1900 auf. dann kannst du auch ohne probleme datumsfunktionen darauf anwenden.

    Ilja

    1. nimm Date und fülle das jahr mit einem festen wert wie zum beispiel 1900 auf. dann kannst du auch ohne probleme datumsfunktionen darauf anwenden.

      1900 war kein Schaltjahr. Somit wäre es nicht möglich, den 29. Februar 1900
      als korrektes Datum zu speichern.
      Mit einem Schaltjahr, z.B. 1980, fände ich Deinen Vorschlag aber sehr gut.

      Es gibt in MySQL auch eine Möglichkeit, "ungültige" Daten zu speichern, und
      zwar mit dem Modus ALLOW_INVALID_DATES. Dann wird offenbar nur geprüft,
      ob der Monat zwischen 0/1 und 12 liegt und der Tag zwischen 0/1 und 31.
      Ob man so auch Daten speichern kann, bei denen das Jahr 0000 ist, weiss ich nicht.
      Am besten ausprobieren - oder die Doku gründlicher lesen als ich... ;-)

      Links zum MySQL 5.1 Manual:
      Date and Time Types
      SQL Modes => ALLOW_INVALID_DATES

      Ich hoffe, das hilft Dir bzw. dem OP weiter.
      Gruss, Thomas

  5. Danke für eure Antworten. Ich werde die Vorschläge mal durchdenken, welches davon sich am besten für meine Zwecke anbietet. Lösungen sind ja ausreichend vorhanden. Danke nochmal :)

    1. hi,

      falls Du nur mit ganzen Tagen rechnen willst: Der unixTimestamp ist da nicht die richtige Wahl, den gibts außerdem erst seit 1.1.1970.

      Mein Tipp: Nimm den Julianischen Tag, damit ist jeder Tag eindeutig bestimmt. Falls Du mit Perl programmierst: Auf meiner WebSite findest Du ein kleines Modul, was mit ganzen Tagen rechnet, die ab Tag 0 am 1.1.1600 fortlaufend numeriert werden. Der 1.1.2000 hat bspw. die Nummer 146097.

      Hotte