nicht angemeldet
yo,
mir fallen spontan zwei möglichkeiten ein. zum einen kannst du dir eine menge tabellen sparen, indem du zwei entitäten bildest:
1. produkte
2. eigenschaften
in der ersten tabelle stehen natürlich die produkte, in der zweiten die eigenschaften (nicht inhalte), die ein produkt haben kann. das wären also zum beispiel farbe, gewicht, versandart, auflage etc. zwischen den beiden entiäten besteht eine n:m beziehung, sprich es braucht eine zusätzliche beziehungstabelle:
3. produkte_eigenschaften
die spalten wären:
produkt_id
eigenschaft_id
lieferzeit
wert
wobei die ersten zwei spalten einen zusammengesetzten primär-schlüssel bilden. bei lieferzeit wird immer nur die schnellstmögliche lieferzeit abgebildet, die langsameren werden impliziert. der vorteil davon ist zum einen wesentlich weniger tabellen und somit übersichtlicher. auch wenn neue eigenschaften hinzukommen, kann man dies tun, ohne in das daten-layout eingreifen zu müssen. der nachteil besteht darin, dass du die einzelnen eigenschaften wie zum beispiel der farbe nicht verschiedene attribute zuordnen kannst, die nur spezifisch für die farbe sind, da ja sonst alle anderen eigenschaften davon mitbetroffen wären. falls solche individuelle attribute der jweiligen eigenschaften auszuschließen sind, ist dies ein sehr guter weg.
falls du aber lieber für jede eigenschaft eine einzelne entität machen willst, damit du ihnen individuelle attribute zuordnen kannst, dann ist meine frage, ob die lieferzeiten nicht auch von dem produkt abhängt oder nur von der eigenschaft bestimmt wird ?
beispiel farbe, ist dabei die lieferzeit nicht auch davon abhängig, welches produkt hergestellt wird oder bezieht sich die lieferzeit nur so wie du es gemacht hast auf die farbe, sprich ist unabhängig von dem produkt ?
wenn die lieferzeit nämlich auch von dem produkt abhängig ist, dann würde die lieferzeit mit in die beziehungstabelle kommen von farbe und produkte. das wäre wichtig erst einmal abzuklären.
Ilja