datumsfeld Mysql und webform

[vikozo]

guten tag
in einer Webform möchte ich das Datum eingen und zwar "14.03.2007"
Wie muss ich in Mysql das feld definieren - etwa mit Date?

Dann kann ich im Webformular als vorgabe tt.mm.jjjj eingeben das dann einfach überschrieben wird, eventuell sogar das die Punkte da sind und nicht mehr eingegeben werden müssen?

danke für feedbacks
gruss
vincent

[Altrea]

Guten Morgen,

Wie muss ich in Mysql das feld definieren - etwa mit Date?

Ja, das ist der vorgesehene Datentyp. Je nachdem, was du mit dem Datum machen möchtest, bietet sich vielleicht auch ein Integer an, um den Datentyp dann als UNIX-Timestamp abzulegen. Oder wenn das nur den Zeitpunkt festhalten soll, wann der Datenbankeintrag erstellt wurde, bietet MySQL von sich auch auch den Datentyp TIMESTAMP an, der dann automatisch gefüllt werden kann.

Dann kann ich im Webformular als vorgabe tt.mm.jjjj eingeben das dann einfach überschrieben wird

Meinst du also Vorauswahl, oder Hinweistext neben dem Feld?

eventuell sogar das die Punkte da sind und nicht mehr eingegeben werden müssen?

Im Textfeld selbst Kann man das mit bestimmten JavaScript Funktionen realisieren, wovon ich allerdings abraten würde, da ich keins kenne, was wirklich Benutzerfreundlich ist, vorallem bei nachträglichen Änderungen mitten im Feld.

Andere Möglichkeit wäre, das Datumsfeld in 3 Felder zu splitten. Damit umgehst du auch später das Datum auseinanderzupflücken, um es auf den Date Datentyp für MySQL richtig anzuordnen.
Wenn du dir andere Formulare ansiehst, wirst du Datumseingaben häufig in Verbindung mit Select Auswahlfelder antreffen. Auch eine Möglichkeit.

Ich persönlich nutze mittlerweile ein einfaches Eingabefeld für Datumseingaben und prüfe mit JavaScript bei der Eingabe und/oder php nach Abschicken des Formulars, ob das Feld den passenden Wert hat und das Datum gültig ist. Den Benutzer mit bestimmten Eingabehilfen wie gesplitteten Feldern (vllt. sogar als Selects) oder JavaScript Formathilfen unter die Arme zu greifen ist meist nur da sinnvoll, wo ein erhöhtes Fehlerpotential vorhanden ist. Ein Datum dagegen ist so eingängig, dass es für den Benutzer meist am einfachsten zu bedienen ist, wenn er es frei eingeben kann.

danke für feedbacks

Bitte

[Nobbie]

Ja, das ist der vorgesehene Datentyp. Je nachdem, was du mit dem Datum machen möchtest, bietet sich vielleicht auch ein Integer an, um den Datentyp dann als UNIX-Timestamp abzulegen.

Das habe ich zwar Anfangs auch gerne gemacht, aber wenn ich ehrlich bin, ist das Mist. Ich will es begründen:

a) der Unix Timestamp umfasst nur ein kleines "Spektrum" möglicher Datümer (urgs - ist das Mehrzahl von "Datum"). Genau genommen geht es von 1.1.1970 (= 0) bis irgendwo 20xx (ich glaube 2030 o.ä., bin jetzt zu faul das auszurechnen). Dadurch kann man beispielsweise keine Geburtsdaten von Leuten verwalten, die vor 1970 geboren sind.

b) (und das ist ein schlimmes Kriterium): durch die Umwandlung auf INT (statt DATE_TIME) stehen keinerlei der sonst sehr mächtigen Datumsfunktionen von MySQL zur Verfügung. Ein ausgeklügelter Query muss erst umständlich vorberechnet werden, wobei die ganze Datumslogik, die sonst automatisch von den MySQL Funktionen erledigt worden, in das jeweilige Script (PHP o.ä.) ausgelagert werden. Auch eine Indexierung des Datumsfeld hat dann keinen Sinn (geht auch gar nicht bei Integer), so dass ggf. Querys sehr langsam werden können.

c) spätestens das genannte TIMESTAMP Format ist ebenfalls vom Format DATE_TIME. Die ganze Programmierung ist also inkonsistent, wenn man zum einen mit INT arbeitet und das via PHP in ein Datum umrechnet, zum anderen aber dann doch wieder mit MySQL DATE_TIME. Auch lassen sich (erneut) diese Spalten nicht über einen Query vergleichen, da sie verschiedene Typen haben.

Wenn also ein Datum im Datenmodell benötigt wird, sollte man auch die physikalischen Möglichkeiten von MySQL bemühen und das Datum als entsprechenden Typen anlegen. Da nach unserer westlichen Darstellungskonvention ein Datum meistens anders aussieht als intern in MySQL dargestellt, benötigt man lediglich ein paar kleinere (recht triviale) Umformatierungsroutinen.

[Altrea]

Das habe ich zwar Anfangs auch gerne gemacht, aber wenn ich ehrlich bin, ist das Mist

Das sehe ich ähnlich.

a) der Unix Timestamp umfasst nur ein kleines "Spektrum" möglicher Datümer (urgs - ist das Mehrzahl von "Datum").

Datümer, muss ich mir merken

Ich sehe auch nur eine kleine Hand Einsatzszenarien, wo ein UNIX-Timestamp vielleicht Sinn macht, nämlich dort, wo man die Differenz zweier Datums-/Zeitangaben errechnet werden soll. Da dürfte eine einfache mathematische Gleichung deutlich performanter sein als die Datumsfunktionen von php (von denen sowieso noch einige selbst einen UNIX-Timestamp als Parameter erwarten und damit eine Umwandlung erfordern).

b) (und das ist ein schlimmes Kriterium): durch die Umwandlung auf INT (statt DATE_TIME) stehen keinerlei der sonst sehr mächtigen Datumsfunktionen von MySQL zur Verfügung.

Da hast du vermutlich vollkommen recht. Ich muss auch zugeben, dass ich die Möglichkeiten von SQL häufig unzureichend auslote. Je nachdem, was für einen Einsatzzweck man verfolgt würde ich aber eine Scriptlösung vorziehen (besonders dann, wenn sich meine Abfragezeiten oder die Abfrageanzahl dadurch nennenswert erhöhen würden)

c) spätestens das genannte TIMESTAMP Format ist ebenfalls vom Format DATE_TIME. Die ganze Programmierung ist also inkonsistent, wenn man zum einen mit INT arbeitet und das via PHP in ein Datum umrechnet, zum anderen aber dann doch wieder mit MySQL DATE_TIME.

Das sehe ich ein bißchen anders. Wenn man einen guten Grund dafür hat ein Datum als UNIX-Timestamp in der Datenbank speichern zu wollen, sollte man auch den passenden Datentyp wählen, statt den Wert in einen Date Datentyp zu pressen. Dass es wenig Gründe dafür gibt habe ich ja oben schon beschrieben.

Aber ein weiterer Punkt der für DATE spricht ist der Speicherverbrauch. Während Date nur 3 Bytes belegt, sind es bei einem INT 4 Bytes. Das ganze sieht natürlich ganz anders aus, wenn man die Zeit mitspeichern möchte. Ein DateTime verbraucht ganze 8 Bytes.

[Nobbie]

Ein DateTime verbraucht ganze 8 Bytes.

Ich habe mir letzte Woche eine neue Festplatte gekauft, eine EcoGreen von Samsung, Kapazität 1,5TB (= 1.500GB = 1.500.000MB = 1.500.000.000KB = 1.500.000.000.000 Byte), und die hat 86,-€ (inkl. Versand) gekostet.

Ich glaube, da sind 8 Byte für ein Datum statt 4 Byte für ein Small INT noch im bezahlbaren Rahmen....

P.S.:

e nachdem, was für einen Einsatzzweck man verfolgt würde ich aber eine Scriptlösung vorziehen (besonders dann, wenn sich meine Abfragezeiten oder die Abfrageanzahl dadurch nennenswert erhöhen würden)

Stelle Dir mal ein Logfile vor (so wie Apache es beispielsweise schreibt) und die Datensätze stünden in einer MySQL Tabelle, natürlich u.a. mit Datumsfeld, wenn der Zugriff war (natürlich inkl. Uhrzeit). Und jetzt willst Du eine einfache Abfrage starten, wieviele Zugriffe jeweils pro Tag stattgefunden haben (eine einfache Gruppierung). Und dann hast Du das Problem, das Datum als INT gespeichert zu haben... (da dürfte die entsprechende SELECT Anweisung bei echtem Datumsfeld um eine Irrsinnsfaktor schneller laufen als eine Scriptlösung). Und das ist eine Standardanforderung, wie ich jede Menge konstruieren kann, wo eine Scriptlösung gegenüber einem mächtigen Select (denn SQL ist sehr mächtig) jämmerlich versagt.

[vikozo]

Danke für die vielen Infos.

Also benützen tu ich das Datum als normales Datum
heute würde ich den 10.03.2010 eintragen bisher soweit ich überlegt habe muss keine Berechnung anstellen.
Es muss auch nicht nach dem Datum Sortiert werden.

nun man stelle sich vor ich gehe Joggen und möchte wissen wie lange ich für eine Strecke benötigte.

also
09.03.2010 - 90 Minuten
10.03.2010 - 85 Minuten gerannt usw
aber auch
14.08.2009 - 110 Minuten

ganz am Schluss möchte ich fragen können im 2010 wieviel gejogget und hier wäre die antwort 2h 55minuten (Bisher gejogget 3h 45minuten)
und hier schneidet sich auch diese frage viewtopic.php?f=6&t=39665

gruss
Vincent

[Stepke-DSL]

Hallo Vincent,

Kleiner Vorschlag, für das Datumsfeld nimmst du DATE / DATETIME und für das Feld mit den Minuten nimmst du INT.
Dadurch kannst du MySQL die Berechnungen machen lassen, kannst sortieren (falls später mal nötig), usw.

Falls du bei der Berechnung (SQL) Hilfe brauchst, sag bescheid.

MfG Stepke