nicht angemeldet
Moin!
Dann mach doch einfach mal ohne Normalisierung. Wird nichts gutes bei rauskommen, wenn du die Daten in der Datenbank denn mal so richtig komplexen Analyen unterziehen willst.
Könntest du evtl. ein Beispiel konstruieren, an dem sich das nachvollziehen lässt?
Ok. Du hast eine Datenbank, die folgende Inhalt abbildet:
Kunden, die Gegenstände kaufen. Ein Gegenstand gehört zu einem Lieferant und zu einer Warengruppe.
Das kannst du alles in eine Tabelle hauen:
Kundenname | Gegenstand | Lieferant | Warengruppe
Das loggt dann mehr oder weniger alle Vorgänge. Und dürfte vermutlich auch relativ schnell gehen beim Schreibvorgang.
Das Problem dabei ist nur: Wo ist deine Auswahlliste von Lieferanten, die existieren? Wo ist deine Liste von Warengruppen, die definiert wurden? Wie kriegst du es ohne diese separaten Listen performant hin, das Eingabeformular mit zwei entsprechenden Auswahllisten anzureichern?
Antwort: Gar nicht. Du müßtest, um zumindest alle bereits in der Tabelle existierenden Einträge bei "Lieferant" und "Warengruppe", ein "SELECT DISTINCT" oder "GROUP BY" ausführen - welches seinerseits erst einmal die GESAMTE Tabelle durchscannt, um dann doppelte Einträge zu eliminieren.
Klingt das noch in irgendeiner Weise vorteilhaft?
Ich bin gerade beim Datenbankdesign, und da stellt sich nun die Frage: NF, der nicht. Aktuell spricht alles dagegen, da ich längere Rechenzeiten unter allen Umständen vermeiden will, ich lasse mich aber auch eines besseren belehren ;-) - und jetzt kommt ihr.
DB-Design hängt immer von den Daten, ihrer Struktur, und der zu erfüllenden Aufgabe ab.
Da du davon noch nichts berichtet hast, kann man dir keinen Rat geben.
- Sven Rautenberg
"Love your nation - respect the others."