[SQL] Aufbau von Kategorien in der Datenbank

M

mister-t

Gast
Ich bin gerade am Aufbau einer Website und mache eine Datenbank dazu. Jetzt habe ich eine Frage zum Aufbau der Kategorien (also) wie ich die Tabellen aufbauen soll.

Zur Vorstellung:
- Kategorie1​
- Kategorie2​
- Artikel​

In diesem Beispiel könnte der Artikel (oder Beitrag) nicht in der Kategorie1 sein, sondern nur in der Kategorie2.

Tabellen hätte ich so gedacht:
Artikel
- id
- usw...
- kat1_id
- kat2_id

Kategorie
- id
- usw..-
 
Verstehe ich das richtig, dass ein Artikel mindestens in einer Kategorie beinhaltet sein kann?

Quasi eine M:N-Beziehung zwischen Artikel und Kategorie?
Unbenannt.PNG
 
Ja dies wäre möglich, aber dazu sollte es Über-/Unterkategorien geben zum Biepsiel:
Computer->Komponenten->Grafikkarte->Und jezt der Artikel...

Das ist mein Problem, wie soll ich das lösen, mit den Unterkategorien...?
 
Eine Möglichkeit wäre es, wenn du in der Tabelle Kategorie noch ein Element "kategorie_parent" einfügst. Hier gibts du dann die ID der Oberkategorie an.

Zweite Möglichkeit, ein Verweis auf die eigene Tabelle.
 

Anhänge

  • Unbenannt.PNG
    Unbenannt.PNG
    51,5 KB · Aufrufe: 882
Zuletzt bearbeitet:
Kategorie
- id
- parentId
- usw...
 
Tabelle Kategorie:
ID, Name, UeberKategorieID

Im Root des Baumes ist die UeberKategorieID null, -1 whatever...

Dann braucht Dein Artikel auch nur eine KategorieID, die über geordneten ergeben sich dann aus der Kategorie Tabelle... Es sei denn ein Artikel soll in mehreren Kategorien auftauchen, die in verschiedenen Trees des Baums liegen.
 
Eventuell nur die ID der Kategorie speichern. Dazu dann zusätzlich eine Tabelle mit der Hierarchie, also Computer ist Elternelement von Komponenten => Komponenten ist Elternelement von Grafikkarten => ...


zu langsam
 
Also ich habe sie im Moment so...

Meint ihr so?
kat.JPG

Und dann am Schluss uuk_id im Artikel.
 
uuk heißt unterunterkategorie?
uk heißt unterkategorie?

Damit machst du die Datenbank deutlich zu groß, als sie sein müsste. Siehe den ANhang in meinem Post #4
 
Nein Du hast nur eine Tabelle für die Kategorie. Die Einträge in der Tabelle verweisen auf die über geordneten Einträge in der selben Tabelle. Das lässt dann eine beliebig tiefe Verschachtelung zu, ohne für jede Ebene eine Tabelle anlegen zu müssen. Nachteil für Dich ist wahrscheinlich, dass Du eine rekursive Funktion brauchst um die gesamte Struktur zusammen zu bauen, das ist für Anfänger manchmal schwierig. Aber der einzig vernünftige Weg, um nicht in Limitierungen zu laufen und um den Wartungsaufwand gering zu halten.

In die Kategorie Tabelle würde ich auch eine Spalte mit einem Sortierkriterium einbauen (einfach eine aufsteigende Zahl innerhalb einer Ebene), um manuellen Einfluss auf die Sortierung der Kategorien nehmen zu können...
 
Ah okey könntest du mir mal ein Beispiel zeigen oder noch klarer erklären? Mir ist es wichitg, dass ich die Normalformen erfülle! ;)

Meinst du mit übergeordnete Einträge einfach die, die schon erstellt wurden?
 
Zuletzt bearbeitet:
Mit Übergeordnet meint er die übergeordneten Kategorien.

Dein Artikel zeigt auf eine Kategorie K5, diese in der selbe Tabelle auf K4, diese auf K3, diese auf K2, diese auf K1 und K1 hat keinen Zeiger auf eine weitere Kategorie ist also Wurzel des Kategorie-Baums. Inder Art wie du es machen willst bräuchstest du im schlimmsten Fall für jede Kategorie-Ebene eine Tabelle.
 
Wenn du sowas mal in Aktion sehen willst, setz dir schnell ein Contao auf und guck, wie da der Seitenbaum gelöst ist. Selbes Prinzip.
 
Oke danke ich hab hier nur kurz mal ein Bild, so wäre doch noch eine gute Möglichkeit?

kategorie.JPG
 

Anhänge

  • kategorie.JPG
    kategorie.JPG
    35,8 KB · Aufrufe: 299
Zuletzt bearbeitet:
Möglich, dass es so auch geht, 2 Tabellen sind aber überflüssig und es wird die Wartung erschweren, da durchzublicken. Im Anhang eine Visualisierung, wie ich es meine.

kategorien.png
 
Aha danke vielmals!!
Ich dachte, wenn ich eine zweite Tabelle mache, habe ich keine Redundanzen (Beispiel: CPU->Chip, GPU->Chip) dann kommt das gleiche Wort zweimal vor.....
Und wäre nicht die Spalte "Ebene" praktisch, damit man zum Beispiel ein Select macht und sagt alle dieser Ebene ausgeben?
 
Falls du solche Selects machen willst ist sicherlich die Ebene eine gute Eigenschaft für die Tabelle.

Zu deinem Redundanz-Beispiel: Das ist keine wirkliche Redundanz. Beic Chip von CPU und bei Chip von GPU handelt es sich ja um eindeutig andere Datensätze. K1(Name= CPU, Parent=null); K2(Name=GPU, Parent=null); K3(Name=Chip, Parent=K1); K4(Name=Chip, Parent=K2) ... wenn du jetzt für alle Kategorien die den Namen 'Chip' haben wirklich den gleichen Datensatz erwarten würdest hättest du ein Redudanz-Problem ... aber es ist hier ja vielmehr wie ein Name bei einer Person. Wenn du eine Personaldatenbank hättest würdest du ja auch nicht nur einen "Hans Müller" aufnehmen, sondern die verschiedenen Hans Müller durch einen eindeutigen Schlüssel von einander abtrennen.
 

Ähnliche Themen

Zurück
Oben