nicht angemeldet
ich beschäftige mich gerade mit dem Datenbankentwurf zur Verwaltung von
ca. 600 Artikeln, diese sind wiederum in fünf Produktgruppen unterteilt. Hier ist die Ausgangstabelle (Primärschlüssel ist Art.Nr.):
[...]
... alle Daten könnten doch in einer Tabelle enthalten bleiben, oder?
Ja, so wie du das gemacht hast sieht das erstmal nicht ganz schlecht aus.
Deine Tabelle beinhaltet Artikel mit diversen Eigenschaften, die nur zum Artikel gehören.
Obsthändler Krämer mischt in seinem Entwurf Kundendaten, Produktdaten und Bestelldaten und erhält damit Redundanzen und Probleme.
Folgendes Szenario:
Die Webseite deines Onlineshops soll zuerst die Produktgruppen zusammen mit einem Erläuterungstext und einem Icon anzeigen. Diese Daten sollen aus der DB abgefragt werden. Der Kunde wählt eine Produktgruppe und sieht dann alle Artikel daraus. Sprich: Jeder Artikel ist einer Produktgruppe zugeordnet.
Dafür brauchst du zwei Tabellen:
Tabelle Produktgruppe mit den Feldern ID, Name, Erlaeuterung, Icon, ...
Tabelle Artikel mit den Feldern ID, Bezeichnung, Langtext, ..., ID_Produktgruppe
Der Name der Produktgruppe gehört nicht in die Tabelle Artikel, sondern wird über ID_Produktgruppe mit der ID aus der Tabelle Produktgruppe verknüpft.
Weiterhin empfiehlt es sich Datenhaltungsspezifika nicht mit den Daten zu vermischen. Der Primärschlüssel wird benötigt, um einen _Datensatz_ anzusprechen, nicht einen _Artikel_.
Man nimmt deshalb als Primärschlüssel etwas generisches (Zahl, GUID, ...). Das gleiche gilt für Felder, die der Verknüpfung dienen (ID_Produktgruppe statt deren Name).
Wenn dir später auffällt, dass die Artikelnummer nicht stimmt und du die änderst, bekommst du ein Problem mit den Daten von Bestellungen, die dann auf eine nicht mehr existierende Artikelnummer verweisen. Ebenso verhält es sich wenn du den Namen einer Produktgruppe ändern willst.