nicht angemeldet
hi Bernhard,
nicht abschrecken lassen. man will dich auf einen fehler aufmerksam machen, dass dein design der tabelle sehr "unschön" ist. ich stelle mal ein paar vermutungen an, da ich deine vorgaben nicht genau kenne und behaupte mal, du hast verschiedene artikel und auch mehrere benutzer, die diese artikel auswählen.
das problem, vor dem du stehst, ist dass die anzahl der ausgewählten artikel variabel ist, als nicht fest steht und von fall zu fall verschieden sein kann. oder mit anderen worten eine benutzer kann mehrere artikel auswählen. und ein artikel, kann bestimmt auch von mehreren benutzern ausgewählt werden. das wäre dann eine n:m beziehung. wenn du nur einen benutzer hast, dann wird es ein wenig einfacher und du hast eine 1:n beziehung. aber ich gehe mal die andere möglichkeit durch.
man könnte n:m (1:n) in einer tabelle abbilden. das bringt aber nur probleme und deswegen ist diese idee nicht zu empfehlen. mein vorschläg wäre:
-
habe eine tabelle für alle artikel, und deren Attribute
-
habe eine tabelle für alle benutzer (sofern es mehrere gibt) und deren attribute
-habe eine dritte tabelle als verbindung der beiden, die beziehungstabelle. dort stehht dann, welcher benutzer (benutzer_id) welchen artikel (artikel_id) ausgewählt hat mit ihren Attributen, zum Beispiel, zu welchen Datum er diesen Artikel ausgewählt hat.
damit kannst du auch ohne probleme skalieren, da du nicht über die spalten gehst, wenn eine benutzer einen weiteren artikel auswählt oder löscht.
Ilja