nicht angemeldet
Hi Heinz
Ja.
Neben profanen Dingen, wie Ort fehlen viel wichtigere Dinge, wie dem Gedankengang, wie und wo die DB erweiterbar sein muß. Das geht dann auch gleichzeitig in das Thema Normalisierung über.Ort ist hinzugefügt. Kd-Datum ist hinzugefügt.
Update
Hm. Dammit könnten wir uns jetzt dran halten. Was ist mit Mobilfunknummer? Was, wenn einer mehrere Nummern hat?
Was, wenn Du unter einem Kunden verschiedene Konditionen verwalten willst? Ist es für Dich interessant, wann der erste Kundenkontakt hergestellt wurde? usw., usw.
Zur Normalisierung sag ich unten, bei tk noch was.
Normalisierung ist wichtig und macht sogar Spaß, wenn man es kann. Aber auch hier muß man für sich selber entscheiden, was wie wichtig ist.
Theoretisch könnte man auch die Kundendaten normalisieren. Kunde hat eine ID oder Kundennummer, der Rest könnte über eine Tabelle Kundendaten der ID oder Kundennummer zugeordnet werden. Macht hier wenig Sinn, aber verdeutlicht Dir, was Normalisierung erreicht. Dem einen Kunden wird nur Strasse, Ort, Tel zugeordnet, dem nächsten werden 3 Telnummern, 2 Strassen, 2 Orte usw. zugeordnet.
Dann solltest Du Dir noch Gedanken darüber machen, welche Daten, wenn sie dynamisch zugeordnet werden, irgendwann problematisch werden könnten, weil sie änderbar sind. Diese mußt Du dann doch ggf. redundant führen oder für diesen Fall Deine DB um eine weitere Tabelle erweitern, die diese Redundanz dann beinhaltet. Beispiel, eine Kundenadresse ändert sich. Dann ist die Frage, ob es für Dich interessant ist, dass er schon Kurzgeschichten unter der alten Adresse geliehen hat, denn dynamisch Daten einsetzen hieße sonst, Historiendaten verfälschen.
Ist alles lösbar, aber die Grundgedanken zu solchen Themen stehen optimalerweise vor Projektbeginn im großen und Ganzen schonmal.
Heinz