SQL - Kategorien mitspeichern

[Ronald Nickel]

Hallo SQL-Profies
Ich bräuchte mal einen Denkanstoß für ein Datenbank-Modell.

Ich möchte die Rubriken/Themen eines Webkataloges für die sich ein eingeloggter Kunde definitiv interessiert (Checkbox jeweils durch Kunden aktiviert) speichern. Nun kann dies durch die Anzahl der Rubriken eine umfangreiche Sache werden. Ich denke nicht das ein Feld mit einem Array oder einer Liste mit den ID der gewählten Rubriken ausreichen wird. Kann mir jemand sagen wie ich das performanter hinbekomme. Die großen Shops speichern ja teilweise auch die bevorzugten Artikel oder Artikelgruppen der User ab. Und das in abartig großen Zahlen. Hat da jemand ne Idee?

Gruß Ronny

 

[Jürgen Auer]

Im Augenblick fallen mir zwei Lösungsmöglichkeiten ein:

Variante 1, stur nach den Normalisierungsregeln: Grundtabelle Nutzer, Grundtabelle Kategorien, Verknüpfungstabelle v_Nutzer_Kategorien mit drei Spalten (Primärschlüssel, NutzerId, KategorienId), jeweils indiziert wird das zwar riesig, sollte aber einem ordentlichen Datenbanksystem als eine typische schmale Tabelle keine Probleme bereiten.

Variante 2, die aber (je nach DB-System) nur für 31/32 oder 63/64 Kategorien funktioniert: Die Kategorien sind mit Primärschlüsseln 1, 2, 4, 8, 16 usw. abgespeichert. Zu jedem Nutzer wird das Bitmuster seiner Kategorien gespeichert (also 3, falls die Kategorien 1 und 2 ausgewählt wurden). Problem: Bei Integer = 4 Byte stehen maximal 32 Werte für Kategorien zur Verfügung, bei BigInt 64. Außerdem sind die Abfragen eine kleine Spur kniffeliger.

PS: Der zweite Typ ist schon ziemlich praktisch und deshalb bei mir fest implementiert: Die Kategorientabelle wäre eine bitSet-Tabelle (der Rest geht automatisch), damit kann man bsp. einer Person verschiedene Sprachkenntnisse (deutsch, englisch, französisch usw.) per Anhaken zuweisen.

 

[Irene]

Das _tönt für mich nach dem klassischen Fall einer n:m Beziehung. In diesem Fall gäbs dazu eine neue Tabelle, z.B. Kunden_Rubriken genannt. Da hinein kommen zwei Felder, einmal die Kunden-ID und einmal die Rubrik-ID. Der Primärschlüssel wird auf die Kombination der beiden Felder gelegt, womit (mindestens bei den MS-Datenbanken) die Kombination auch gleich indiziert wird. Dann würde ich noch Beziehungen setzen (wiederum bei MS-Datenbanken), welche die entsprechenden Felder der Kunden- und der Rubriken-Tabelle mit dieser n:m-Tabelle verknüpft.

Für eine bessere Performance bei den angesprochenen abartig grossen Zahlen

würd ich das Speichern/Löschen für diese Tabelle in Stored Procedures erledigen. Einen Update-SQL sollte es auf dieser Tabelle sowieso nicht geben, da ein Primärschlüssel eigentlich unveränderbar sein sollte.

Griessli
Irene