nicht angemeldet
Hello,
Spieler 1 spielt vom 01.01.2013 bis 02.08.2013 bei Verein 1.
Spieler 1 spielt seit 03.08.2013 bei Verein 2.IMO besser die 1:n-Relation beizubehalten und für das Geschichtliche eine neue Tabelle zu nehmen.
Da dann vielleicht sogar nicht mit ID für den Verein, sondern direkt Name/Ort, sowas kann sich schließlich auch mal ändern.
Aber die von Andreas geschilderte Relation betrifft sogenannte "Bewegungsdaten" und nicht etwa "Stammdaten" oder "Historiedaten", also "Logbuch"
Hier nochmal eine ganz angenehm lesbare Definition der Begriffe:
http://www.tu-chemnitz.de/wirtschaft/sapr3/dynamics/wbt/course/292/content.3613.8.1.html
Historie- und Bewegungsdaten klassifizieren dabei den gleichen Typ, nur mit dem Unterschied, dass sich Historiedaten nur auf die Meta-daten von "wer wann welche Operation" beziehen und die Bewegungsdaten auf die kaufmännischen Daten "wer wann was wieviel preis lieferzeit ..." beziehen.
Die darf man eigentlich gar nicht ausblenden, wenn sie denkbar ist.
Die m:n-Beziehung war gemeint
Wenn sie beim Entwurf des Datendesigns auch nur latent ins Hinterhirn rückt, dann sollte man die nach vorne holen und auf jeden Fall berücksichtigen. Anderenfalls sollte man sie als Softwareentwickler dediziert im Entwicklungsvertrag ausschließen :-O
Denn sie kommt zu geschätzten 1% der Fälle doch vor. Und das gibt dann mächtig Ärger!
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
MudGuard