MySQL Frage zur struktur

[Manfred Kuhn]

hallo zusammen!

bis jetzt habe ich immer mit über gewöhnliche txt dateien meine informationen abgespeichert um sie wieder aufzurufen, das klappt sehr gut, deshalb möchte ich mich jetzt (mit perl) an MySQL wagen. ich möchte nicht schon zu beginn einen fehler machen den ich mir am ende so gar nicht mehr abgewöhnen kann daher hole ich lieber rat von euch.

nehmen wir mal an ich besitze eine speditionsfirma und möchte folgende informationen über eine person speichern und auch wieder abrufen: name, vorname, geburtstdatum, geschlecht, abfahrt ziel 1, ankuft ziel 1, abfahr ziel 2, ankuft ziel 2 (ziel 3,4,5 usw.).
ich würde das jetzt so machen, eine tabelle mit dem namen "mitarbeiter" erstellen wo dann die informationen: name, vorname, geburtstdatum und geschlecht gespeichert wird (von allen mitarbeitern) und eine tabelle mit dem namen "fahrzeiten mitarbeiter" mit den abfahrt- und ankuftszeiten (welche nach belieben erweitert werden kann). ich dachte mir, ich mache für jeden mitarbeiter eine eigene "fahrzeiten"-tabelle der besseren übersicht.

würdet ihr das genauso machen oder wäre es vielleicht sogar zu optimieren?

vielen lieben dank schon mal im vorraus

[Ilja]

moin,

ich möchte nicht schon zu beginn einen fehler machen den ich mir am ende so gar nicht mehr abgewöhnen kann daher hole ich lieber rat von euch.

fehler gehören zum geschäft und am anfang würde ich sie sogar noch nicht mal vermeiden, sondern einfach mal ausprobieren. selbst profis machen immer wider fehler.

ich würde das jetzt so machen, eine tabelle mit dem namen "mitarbeiter" erstellen wo dann die informationen: name, vorname, geburtstdatum und geschlecht gespeichert wird (von allen mitarbeitern)

hört sich schon mal gut an, wobei ich noch einen künstlichen primärschlüssel hinzufügen würden. schließlich brauchst du ja auch eine möglichkeit, jeden datensatz eindeutig anzusprechen.

und eine tabelle mit dem namen "fahrzeiten mitarbeiter" mit den abfahrt- und ankuftszeiten (welche nach belieben erweitert werden kann). ich dachte mir, ich mache für jeden mitarbeiter eine eigene "fahrzeiten"-tabelle der besseren übersicht.

zum einen solltest du sonderzeichen im tabellen namen weglassen, also auch keine leerzeichen. zum anderen bloss nicht eine tabelle pro mitarbeiter, sondern eine für alle (wie bei den musketieren). in der tabelle gibt es dann noch den verweis auf den jeweiligen mitarbeiter als fremdschlüssel und schon passt es. in der tabelle fahrzeiten_mitarbeiter (die ich einfach nur Touren nennen würde) brauchst du auch noch einen primärschlüssel.

Ilja

[Manfred Kuhn]

hallo zusammen. danke Ilja!

also das mit den namen/sonderzeichen usw. wird natürlich ganz anders aussehen. das mit dem schlüssel werde ich vermutlich auch so machen.
ich komme gerade bei dem zum grübeln:

zum anderen bloss nicht eine tabelle pro mitarbeiter, sondern eine für alle (wie bei den musketieren).

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. 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?
und wie wird das dann gespeichert? wild durcheinander oder alphabetisch?

vielen lieben danke im vorraus

[Ilja]

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

[EKKi]

Mahlzeit Manfred Kuhn,

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. 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.

Dann solltest Du genau analysieren und spezifizieren, welches Objekt bzw. welche Entität welche Eigenschaften und welche Beziehungen zu anderen hat ... wenn Du das sauber hinbekommen hast, ist ein entsprechend normalisiertes Datenmodell in der Regel problemlos umsetzbar.

würde es dann nicht die tabelle sprengen?

Nein.

und wie wird das dann gespeichert? wild durcheinander oder alphabetisch?

Inwiefern spielt das eine Rolle? Du kannst bei der Abfrage der Daten nahezu beliebige Filter- und Sortierkriterien anwenden (je nach Datenbanksystem, dessen Version und SQL-Dialekt), die Art und Weise der Speicherung ist vollkommen irrelevant.

MfG,
EKKi

[Ilja]

moin,

wenn Du das sauber hinbekommen hast, ist ein entsprechend normalisiertes Datenmodell in der Regel problemlos umsetzbar.

ich halte die normalformen erstens für sehr unpraktikabel und zweitens werden sie sogar in der wiki falsch erklärt, wie eigentlich fast immer. aber um es auf den punkt zu bringen, leicht ist bei normalisierung schon mal der falsche ausdruck.

Ilja