Da fängt aber schon das erste Problem an, bzw. taucht die Frage auf Was ist sinnvoll?
Das ist eine gute Frage! für einen größeren Adressbestand ist es bestimmt sinnvoll Adressen in Orte,PLZ... zu zerlegen. Für 10 oder 20 Datensätze wäre das Overkill. Da Du aber das SuperDuperBestelltool schreiben wirst, wäre es nicht sinnvoll, diese Fragestellung zu ignorieren.
Wie solltest Du vorgehen?
Zunächst was willst du mit dieser Datenbank erledigen. Bestellungen! ist klar, aber für welche Vorgänge sollen hier die Daten bevorratet werden?
Wie ist ein Bestellvorgang aufgebaut?
1) Brief/Mail/Telefonat über Gegenstand,Menge,Liefertermin,Zahlungsbedingegen mit/an den Lieferanten. (Wer ist eigentlich der Besteller und wer ist der Lieferant?)
2)Warten auf die Lieferung (wann sollte nochmals was geliefert werden? Haben wir eigentlich genug Platz im Lager?)
3) Die Lieferung trifft ein. Stimmt die Menge, ist der Termin eingehalten worden? wurde überhaupt das richtige geliefert? Gibt es mehrere Orte an denen angeliefert werden könnte und ist am richtigen angeliefert worden?
4) eine Notiz/Mail.. an die Buchhaltung über die erfolgte Lieferung, damit sie weiß was mit der Rechnung die demnächst kommt, zu passieren hat.
Und jetzt ist die Frage, welche Daten fallen an? z.B. Lieferantenadresse. Reicht da
Kautschuk und Co und Hintertupfingen oder hängen da vielleicht noch ein paar Angestellte dahinter, die eine Neujahrsgruß erhalten sollen? Reicht für diese Angestellten ein Memofeld oder sollen es doch eigenständige Datensätze sein?
Und so oder so ähnlich solltest Du Dich mit Bleistift und Papier durch Dein Problem hangeln.
Und immer wenn Du Daten, die du an mehr als einer Stelle benötigst, erkennst, dann hast Du Futter für die
DB gefunden.
Und wenn Du dann weißt welche Daten in Deiner
DB zu finden sein sollen, dann machst Du Dir Gedanken über die Datenorganisation (Tabellen und Inhalte)
und dann...
dann suchst Du Dir eine
DB aus und fängst an zu programmieren.
Gruß
K-H