Fragen zur Struktur einer DB

[Chris]

Hallo,

ich weiß nicht genau, wie ich meine Daten in der DB strukturieren soll.

Es geht um einen Haufen Datensätze, die alle schon in einer Tabelle 'all_data' stehen.

id | besitzer | typ | groesse | ...
-----------------------------------

Diese sollen nun von verschiedenen Usern zu individuellen Listen zusammengefasst werden können. Jeder User hat also eine variable Anzahl an Listen.
So eine Liste besteht dann also eigentlich nur aus den IDs der Datensätze.
Da nun aber sowohl die Anzahl der User als auch die Anzahl der Listen variabel sind, frage ich mich, wie das am besten strukturiert werden kann.

Z.B. habe ich mir überlegt, dass jeder User eine eigene Tabelle bekommt, etwa '<username>_lists' und in dieser Tabelle gibt es zwei Spalten
id | Listen
-----------
Die id ist die ID des Datensatzes, die in 'all_data' verwendet wird und in 'Listen' stehen die Namen aller Listen dieses Users, zu der dieser Datensatz gehören soll.
Dann müsste ich für eine bestimmte Liste immer ein "WHERE Listen LIKE '%<Listenname>%'" ausführen.
Nun frage ich mich, ob das vielleicht unpraktisch ist, da ich auch Kommata in Listennamen verbieten oder gesondert behandeln müsste.

Eine weitere Idee wäre, dass ich statt dem Feld 'Listen' für jede Liste des Users eine Spalte anlege
id | Liste1 | Liste2 | ...
---------------------------
und als Wert 0 oder 1 eintrage. Dann wären die Abfragen bestimmt einiges schneller, aber die Anzahl der Spalten wäre dann variabel.

Auch würde ich gerne möglichst einfach die Namen aller Listen eines Users bestimmen können und das ist bei beiden Varianten zwar machbar, aber nicht unbedingt schön.

Ich hoffe, ihr habt bessere Ideen oder Vorschläge. :-)
Danke schonmal und Grüße
Chris

[alpman]

Hallo Chris,

Platziere ID des Users bei den Listen:

Tabelle User: id, name, ...
Tabelle Liste: id, user_id, ...

Dann kannst Du z.B. alle Listen eines bestimmten Users an dessen ID bestimmen:

SELECT (...) FROM Liste WHERE user_id = 12;

Viele Grüße,

Stefan

[Frank (no reg)]

Hi,

du hast also 3 Entitäten/Objekte

• Benutzer
• Liste
• Nutzdatensatz

korrekt?

Es gelten folgende Relationen:

• Benutzer : Liste            = 1:n
  (jede Liste kann nur einem Benutzer gehören, ein Benutzer kann mehrere Listen haben)
• Liste: Nutzdatensatz        = 1:n
  (ein Datensatz kann nur in einer Liste sein, aber eine Liste kann beliebig viele Nutzdatensätze haben)
• Benutzer : Nutzdatensatz    = 1:n

korrekt? Oder sollen die eigentlichen Nutzdatensätze (all_data) auch gemeinsam in verschiedenen Listen von verschiedenen Benutzern enthalten sein? Dann hättest du

• Benutzer : Liste            = 1:n
  (jede Liste kann nur einem Benutzer gehören, ein Benutzer kann mehrere Listen haben)
• Liste: Nutzdatensatz        = m:n
  (ein Datensatz kann in beliebig vielen Listen sein, eine Liste kann beliebig viele Nutzdatensätze haben)
• Benutzer : Nutzdatensatz    = m:n

Je nach Beziehung benötigst du zusätzliche Verknüpfungstabellen (für m:n) oder auch nicht (1:n = Parent->Child)

Für Parent-Child Beziehungen erzeugst du in der Child-Tabelle (z.b. Liste) einen Fremdschlüssel (Foreign Key) auf die Id des Parent-Objektes (in dem Fall: Benutzer).

Beginne bei Datenmodellierung am besten immer mit einem Blatt Papier und einem Stift und zeichne dir die Fakten darauf auf, ziehe dann Verbindungslinien zwischen den Fakten und beschreibe jene => erkenne die Zusammenhänge. Dann werden viele Sachen plötzlich klar wie Kloßbrühe, z.b. die Umsetzung in ein physikalisches Modell.

Ciao, Frank

[Christian]

Hi,

Danke für die Aufdröselung meiner Daten!
Es liegt der zweite Fall vor mit der m:n-Beziehung zwischen Liste und Nutzdatensatz.
Ich hab mir das auch nochmal aufgemalt und jetzt auch viel mehr Klarheit :) Die Begriffe "m:n-Beziehung" und Verknüpfungstabelle kannte ich noch nicht. Nach ein bisschen googlen weiß ich jetzt auch, was das ist, und wie es funktioniert. Diese Lösung hab ich gesucht, aber bin nicht selber draufgekommen.

Danke nochmals und Grüße
Christian

[Ilja]

yo,

die idee mit den eigenen tabellen für jeden user oder mehrer spalten für jede liste der user ganz schnell verwerfen und nie wieder rausholen. ;-)

frank hat es schon angesprochen, du musst geeignete objekttabellen und beziehungstabellen anlegen, die genau das abbilden können, was du willst. es macht wenig sind, tabellen oder neue spalten anzulegen, wenn ein neuer user oder eine neue liste erstellt wird. das wäre ganz ganz grausam.....

auch wenn es sich wiederholt, will ich es noch mal darlegen, was du brauchst:

• Tabelle User, nimmt alle Userdaten auf. die tabelle liegt quasi schon vor.

• Tabelle Liste, nimmt den Listenname und die id des Users auf, dem sie gehört, sprich ein Fremdschlüssel, der auf die User tabelle zeigt. notfalls noch andere daten, die den listen-datensätzen zugeordnet werden sollen, wie zum beispiel das datum, wann die liste erstellst wurde, etc.

• Tabelle All_Data (schrecklicher name), die tabelle bleibt so bestehen, wie sie ist, liegt also auch schon vor.

• Tabelle Liste_Data, diese Tabelle hat zwei fremdschlüssel, nämlich den der tabelle liste und den der tabelle all_data. somit kannst du jedem user eine belibige anzahl von listen zuordnen, die beliebig viele datensätze aus alll_data aufnehmen können.

thats it, wenn man will, kann man der beziehungstabelle Liste_Data noch einen eigenen primary key geben oder aber einen zusammengestzten  aus deb beiden fremdschlüsseln, beides ist eine gute lösung.

Ilja

[_King Lully]

thats it, wenn man will, kann man der beziehungstabelle Liste_Data noch einen eigenen primary key geben oder aber einen zusammengestzten  aus deb beiden fremdschlüsseln, beides ist eine gute lösung.

Schreckliche Tabellennamen, aber dafür scheint der Fragesteller verantwortlich zu sein. Zur "n:m"-Tabelle:

• Zwar schlanker und möglicherweise performanter der zusammengesetzte Primärschlüssel, zudem wird so auch sichergestellt, dass eine Zuordnung nicht mehrfach in die Datenbasis gelangt ("Harald trinkt gerne Coca-Cola, Harald trinkt gerne Coca-Cola, Harald trinkt gerne Coca-Cola..."), allerdings sei vor zusammengesetzten und/oder bedeutungstragenden Primärschlüssel an dieser Stelle ausdrücklich gewarnt. Bei späteren "Datenarbeiten" entsteht dann nämlich künstliche Komplexität.
• Also besser, wie auch von Ilja in Betracht gezogen, einen eigenen Primärschlüssel verwenden für die "n:m".
• Um das "Harald/CC-Problem" zu bearbeiten einen unique index auf die Kombination der beiden Fremdschlüssel setzen.

[Ilja]

yo,

• Um das "Harald/CC-Problem" zu bearbeiten einen unique index auf die Kombination der beiden Fremdschlüssel setzen.

ich dachte eher an unique UND not null...

Ilja

[Christian]

Danke auch euch beiden!
Ihr habt mir noch ein paar Infos geliefert, die ich sonst noch hätte ergooglen müssen. Sehr praktisch :-)
Die Tabellennamen sind wirklich nicht schön, aber die ändern sich auch noch.

Grüße
Chris

[_King Lully]

• Um das "Harald/CC-Problem" zu bearbeiten einen unique index auf die Kombination der beiden Fremdschlüssel setzen.

ich dachte eher an unique UND not null...

NULL wird immer gerne vergessen.   ;)

Also, bei Fremdschlüsseln, die zwingend verweisen müssen, immer die Einstellung "not nullable" setzen, gerade bei "n:m"s eine Selbstverständlichkeit.