Autor Beitrag
Palladin007
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1282
Erhaltene Danke: 182

Windows 11 x64 Pro
C# (Visual Studio Preview)
BeitragVerfasst: Mi 11.12.13 19:34 
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ß


Zuletzt bearbeitet von Palladin007 am Mi 11.12.13 20:03, insgesamt 1-mal bearbeitet
Ralf Jansen
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4700
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1282
Erhaltene Danke: 182

Windows 11 x64 Pro
C# (Visual Studio Preview)
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic star
Beiträge: 4700
Erhaltene Danke: 991


VS2010 Pro, VS2012 Pro, VS2013 Pro, VS2015 Pro, Delphi 7 Pro
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1282
Erhaltene Danke: 182

Windows 11 x64 Pro
C# (Visual Studio Preview)
BeitragVerfasst: 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
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 918
Erhaltene Danke: 158

Win 10
VS 2013, VS2015
BeitragVerfasst: 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 Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1282
Erhaltene Danke: 182

Windows 11 x64 Pro
C# (Visual Studio Preview)
BeitragVerfasst: 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