MySQL Nested Sets, eine Tabelle für alle Sektionen *** erledigt***

[strolch00]

Hi @all,

is vielleicht ein etwas komischer Titel, aber ich möchte folgendes vorab klären bevor ich mich ransetze.

Also bei Nested Sets ist es ja so das jedes "Teil" eine Wurzel haben muss, also ich kann nicht einfach eine Tabelle anlegen und dann mit den childs beginnen, zumindest wenn ich das richtig verstanden habe.

Gehe ich da auch richtig in der Annahme das ich mehrere "Teile" in eine Tabelle machen kann mit Nested Sets.

Als Bespiel sei mal FAQ und AGB genannt.

die Tabelle schaut wie folgt aus:

CREATE TABLE IF NOT EXISTS `categories` (
  `id` mediumint(3) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `lft` smallint(2) unsigned NOT NULL,
  `rgt` smallint(2) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `lft` (`lft`,`rgt`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

Meine Wurzelen sind dann jeweils faq und agb und darunter die Childs mit lft und rgt geordnet. Ist dies so korrekt und sinnvoll oder sollte ich doch lieber für die jeweiligen Sachen eine eigene Tabelle machen.

Rein logisch müsste es doch so sinnvoll sein, ich wollte nur nochmal nachfragen um sicher zu sein.

 

[ice-breaker]

Hättest du statt von "Teilen" von Bäumen gesprochen, hätte man wenigstens auf Anhieb verstanden, was du möchtest.
Du kannst natürlich verschiedene Bäume (also mehrere Wurzeln) in eine Tabelle packen, aber du solltest jedem Element dann auch eine Identifikation[1] geben zu welchem Baum der Eintrag gehört.
Es gibt noch Erweiterungen des NestedSet-Modells mit parent_ids (es ist leichter alle direkten Kindern zu finden) oder einem Attribut, was die Tiefe des Elementes speichert (die Tiefe ist in purem SQL leichter zu ermitteln), solltest du mal googlen, hat teilweise gewisse Vorteile/Nachteile.

[1] https://develnet.org/der-aufbau-eines-nested-sets-baumes.html

 

[strolch00]

Richtig das Bäume is mir auf Anhieb net eingefallen
Wie meinst Du das genau Ice, meinst du sowas wie eine parant_id?
Ich habe nämlich eigentlich folgende Aussage im Kopf:

"LFT und RGT aller Nachfahren liegen zwischen den LFT- und RGT-Werten der Vorfahren".

*edit als Anhang nochmal folgendes SQL zum verdeutlichen, einfach mit paar sinnlosen Daten gefüllt(Fehler können existieren, hab ich kurz mit Hand aus dem Stehgreif gefüllt:

CREATE TABLE IF NOT EXISTS `categories` (
  `id` mediumint(3) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) COLLATE utf8_unicode_ci NOT NULL,
  `lft` smallint(2) unsigned NOT NULL,
  `rgt` smallint(2) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  KEY `lft` (`lft`,`rgt`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=14 ;
 
--
-- Daten für Tabelle `categories`
--
 
INSERT INTO `categories` (`id`, `name`, `lft`, `rgt`) VALUES
(1, 'BONUSACTION', 1, 14),
(2, 'Geld verdienen', 2, 11),
(3, 'paid4 start', 3, 10),
(4, 'paid4 klick', 4, 9),
(5, 'paid4 read', 5, 8),
(6, 'paid4 other', 6, 7),
(7, 'Gewinnspiele', 12, 13),
(8, 'FAQ', 15, 0),
(9, 'User', 16, 19),
(10, 'Auszahlungen', 17, 18),
(11, 'sponsoren', 20, 25),
(12, 'Werbeguthaben', 21, 24),
(13, 'Tragging', 22, 23);

Alle groß geschriebenen sind die Wurzelknoten.

 

[ice-breaker]

schau meinen Post nochmal an, hab eben nochmal umgeschrieben, da ist auch ein Link zu dem was ich mit Identifikation meine (als root_id bezeichnet).

Neue Anmerkung: achte darauf, dass der Baum zu jedem Zeitpunkt konsistent ist, dass keine anderen Abfragen den Baum modifizieren können, man kann das NestedSet-Modell nämlich sehr schnell mit parallelen Schreiboperationen zerschießen.

 

[strolch00]

Ah, ok danke Dir. Hatte in der Zwischenzeit auch meine Seite man komplett genauer gelsen und habe auch folgendes gefunden.

Also genau das was Du meinstes, danke nochmal.