nicht angemeldet
moin,
nehmen wir mal an die abfahrts- und ankunftszeiten haben unter anderem noch einen bericht, wann wieviel und wo getankt wurde, ob es probleme gab, wie die waren nach den einzelnen stationen aussieht usw.
datenmodellierung ist wohl neben tuning die königsdiziplin im kontext von datenbanken. das problem ist, dass sich fehler im design später oftmals nur mit viel aufwand korrigieren lassen. deshalb macht macht es sinn, sich im vorfeld dazu viel gedanken zu machen. des weiteren stellt sich die frage, ob dieses modell, was du gerade entwirfst, auch mal in den produktiv betrieb übergehen soll. wenn nicht, kann man einfach mal drauf losprobieren, ansonsten wäre professionelle hilfe angebracht.
wie auch immer, ich würde mir erst einmal gedanken über die entitäten in deinem spezifischen umfeld machen. es gibt bei dir offensichtlich fahrer/mitarbeiter als eine entität, fahrten und Orte/Zielorte würde mir auch noch als eine entität einfallen, etc. bei den fahrten kannst du dann die entsprechenden attribute wie fahrtbeginn, fahrtende zuordnen. dazu würden dann auch die fahrberichte gehören.
nehmen wir einfach mal an es handelt sich um einen DIN A4 bericht und habe mehr als 1000 fahrer die täglich eine runde fahren. würde es dann nicht die tabelle sprengen?
nein, heutige dbms sind für recht großen datenmengen ausgelegt, mehr als 1 millionen datensätze in einer tabelle sind keine seltenheit mehr. und sie dann doch mal zu gros wird, hat man immer noch andere möglichkeiten wie die partitiionierung einer tabelle, so dass man nicht das selbe objekt mehrfach anlegen musss.
und wie wird das dann gespeichert? wild durcheinander oder alphabetisch?
"wild durcheinander", wobei nicht wirklich wild. in aller regel werden die datensätze schon ein wenig in der reihenfolge gespeichert, wie du sie anlegst und man könnte glauben, es würde ein festes system dahinter stecken.. aber du kannst dich darauf nicht verlasen. rdbms basieren auf der mengenleere und mengen sind grundsätzlich unsortiert und so sollte man tabellen auch sehen.
Ilja