Palladin007 - Mi 11.12.13 19:34
Titel: Datetime als Key, wenn Tag immer 0 ist

---

Moin,

ich möchte mir ein kleines Tool schreiben, das Monat für Monat meine Ausgaben und Einkünfte verwaltet.

In der Datenbank-Tabelle soll dann also Monat für Monat eine neue Zeile angelegt werden.

Nun hab ich mir gedacht: Warum nicht das Datum als Schlüssel nehmen? Das ist eindeutig und ich kann in anderen Tabellen auch Monate in der Zukunft eintragen, ohne sie vorher anzulegen. (Bei z.B. Ratenzahlungen)

Klar, ich kann auch weiterhin einen simplen Schlüssel von z.B. int mit schleifen, würde aber gerne datetime nehmen.



Meine Frage ist nun: Kann das Komplikationen geben, sowohl aktuell, oder auch in eventuellen zukünftigen Ständen der Software?

Gruß

Ralf Jansen - Mi 11.12.13 19:44

---

Datetime wird in den meisten System als float dargestellt mit den entsprechenden Problemen beim vergleichen (nur weil etwas vordergründig gleich aussieht muß es noch lang nicht gleich sein). Insofern würde ich von DateTimes genauso wie von Floatingpoint values als Key abraten.

Palladin007 - Mi 11.12.13 19:55

---

Und wenn ich im Vorneherein die Tage komplett 0 setze? Die sind für mein Vorhaben egal, da ich die Tage dann nochmal extra vom ersten Tag des Monats aus zähle.


Aber schon mal danke für den Tipp. Wenn das mit dem 0 setzen der Tage keinen Unterschied macht, dann nutze ich halt weiterhin die gute alte int-ID.


PS:

Hab mal den unpassenden Titel angepasst. :D
Wollte vorher eine andere Frage stellen, die sich dann aber schon selber geklärt hat.
Ich hab den Titel vergessen zu ändern. ^^

Ralf Jansen - Mi 11.12.13 22:06

---

Zitat:

Aber schon mal danke für den Tipp. Wenn das mit dem 0 setzen der Tage keinen Unterschied macht, dann nutze ich halt weiterhin die gute alte int-ID.

Lass es mich so sagen es mag jetzt funktionieren. Aber wenn es um Daten geht gilt immer "Daten leben länger als Programme". In der Software kann man ruhig alles ausnutzen was gerade opportun ist und die Technik hergibt aber bei den Daten sollte immer vorsichtiger Konservatismus walten. Das nächste Framework das man versucht über diese Daten zu legen mag schon daran verzweifeln.

Ich würde immer simple nicht zusammengesetzte Datentypen für Schlüssel verwenden. Und simpel sind an der Stelle nur Integer (von short bis GUID). Die funktionieren immer egal was man tut. Ich stehe mittlerweile sogar auf dem Standpunkt das innerhalb eines System alle Tabellen bei den PKs gleich aufgebaut sein müssen. Nur so kann man später wenn irgendwas nachträglich handgemachtes dran gefummelt werden muss (von Versionierung, Historisierung, Logging bis zu einfachen Replikationsszenarien) einen generischen Ansatz wählen und muß sich nicht mit Sonderfällen rumschlagen.

In diesem konkreten Fall hier hindert dich ja keiner daran das Datum als Feld neben dem PK zu verwenden einen unique sorted Index (auch wenn das genau wie beim PK nicht hilft wenn die Zeit doch mal eine Millisekunde off ist) drauf zu packen und im Anwendungsfall wo ein Datum hilft den PK eben PK sein lassen und ihn schlicht zu ignorieren.

Palladin007 - Mi 11.12.13 23:50

---

Gut, dann lasse ich die ID als integer ^^

Zitat:

auch wenn das genau wie beim PK nicht hilft wenn die Zeit doch mal eine Millisekunde off ist

Dem wirke ich ja entgegen, dass ich einen neuen Datensatz nur dann anlege, wenn in dem aktuellen Monat noch keiner erstellt wurde. Tage und alles darunter sind völlig egal, das behandle ich extra, da z.B. Raten sich ja immer wiederholen und dann zwar an dem Tag und der Zeit hängen, aber Jahr und Monat unwichtig sind.




Auf jeden Fall danke für die Hilfe ^^

jfheins - Do 12.12.13 13:51

---

Wenn du eh nur ganze Monte brauchst, dann ist es doch erst recht sinnfrei dafür Kommazahlen zu benutzen. Da würde ich ja noch eher einen Integer wie "201312" für den Dezember 2013 benutzen.

Palladin007 - Do 12.12.13 17:22

---

Das ist tatsächlich ne gute Idee, dann muss ich nur das Inkrementieren aus den Spalten wieder raus nehmen :D

In der Model-Ebene (MVC-Pattern) baue ich dann ein, dass ich dann gleich zusätzlich den DateTime-Wert abrufen kann, mit dem ich dann ja weiter arbeiten möchte und damit ist das Problem im Prinzip gelöst.
SQL bietet ja auch die Möglichkeiten, das aktuelle Datum mit diesem Int-Wert zu vergleichen, ich konvertiere dann einfach die ID in einen string, bau mir aus Monat und Jahr des aktuellen Datums den passenden String und dann kann ich vergleichen.



Gute Idee, so werde ich's machen, danke :D