Datenbanklogik ....

[Catbytes]

Hallo,

ich kenne die Materie Artikel/Kundenstammdaten auch recht gut - weiß aber immer nocht nicht, was Du genau willst. Soll das eine Branchenübergreifende Kundendatenbank werden?

Sprich: Ein Mauererbetrieb soll genauso Kunden verwalten können wie eine Bank z.B.?

Wenn ja: Da wirst Du um verschiedene Datenbankmodelle gar nicht drum rum kommen. Das machen die großen (SAP, SAGE KHK) genauso. Da gibt es dann Software fürs Baugewerbe, für Einzelhandel etc, weil eben zuviele Unterschiede existieren.

Beispiel: Ein Mauerergewerbe muß nunmal sowas wie "Güteklassen" etc. verwalten, was eine Bank nicht wirklich interessiert.

Wenn es darum geht, daß der Benutzer einfach eigene Infos eingeben kann, wirst Du um eine "offene Datenbank" nicht herum kommen. Sprich eine Oberfläche, wo der Benutzer quasi das Datenbankdesign benutzerspezifischer Felder selbst anlegen/ändern/löschen kann. Da langt als Auswahl quasi:

Feldname (für die Datenbank)
Angezeigter Name (für den Benutzer)
Art (String, Ja, Nein, Zahl etc.)
Länge
Änderbar J/N?

Denke aber auch an solche Unarten, wie das ein Kunde z.B. auch ein Lieferant sein kann. Also Kreditor und Debitor in einer juristischen Person.

Besser ist es dann, Du legst eine Tabelle "Adressen" an - da kannst Du alle Adressen verwalten. Über eine ID vergibst Du dann in der Tabelle "Kontokorrent" Debitoren/Kreditorennummern und andere, Kontokorrenttypische Angaben, wie Zahlungsmodalitäten, Skonto, Lieferart etc.

Du kannst dann nämlich mit der strikten Trennung von den einzelnen Tabellen (also "Adressen" -> "XY") wunderbar noch alle anderen Informationen unterbringen. Du brauchst also noch Tabellen wie "Ansprechpartner", "Lieferadressen", "Kostenstellen" etc.

Über den "Umweg" der einzelnen Adressen-Tabelle kannst Du nämlich dann jede Art von Adressen (nicht nur Kunden mit Kundennummer) verwalten. Also auch Mitarbeiter, Interessenten etc. Das ganze dann per Flag oder Feld "Gruppe" und Du kannst es schön trennen.