Tags-Verwaltung: beste Lösung (DB/Speicher)?

ciss · 05.01.2009, 17:45

Hi,

ich zerbreche mir gerade den Kopf über eine ausgewogene Lösung für den DB-Zugriff einer Schlagwort-Verwaltung.
Aufgebaut ist das ganze so:

Schlagwort-Sets (Tabelle "sets")
Schlagworte ("Tags", Tabelle "tags")
Verschlagwortete Objekte ("Items", Tabelle "items")
Schlagwort-Hierarchie (Tabelle "tree")
Schlagwort-Objekt-Beziehungen (Tabelle "relations")

Die Tabellen sind weiter unten aufgelistet.
Ich habe eine Klasse "tags_db", die die DB-Zugriffe verwalten und auf ein Minimum reduzieren soll. Diese holt sich bei der ersten Instantiierung die Tabelle "sets" aus der DB und speichert sie statisch, alle späteren Abfragen sollen bei Bedarf erfolgen und ebenfalls statisch gespeichert werden. Der Array dafür hat folgende Struktur:

Code:

$SETS = array(
  set_name => array(
    'tags' => array(
      tag_id => tag_name,
      tag_id => tag_name,
      ...),
    'items' => array(
      item_id => item_name,
      item_id => item_name,
      ...),
    'tag_relations' => array(
      tag_id => array( item_id, item_id, ...),
      tag_id => array( item_id, item_id, ...),
      ...),
    'item_relations' => array(
      item_id => array( tag_id, tag_id, ...),
      item_id => array( tag_id, tag_id, ...),
      ...),
    'tree' => array(
      tag_id => array( tag_id, tag_id, ...),
      tag_id => array( tag_id, tag_id, ...),
      ...),
    'options' => array(
      option => wert,
      option => wert,
      ...),
  ),
  set_name => ...
);

Ich hatte diese Struktur gewählt um so wenig wie möglich mit array_search arbeiten und gleichzeitig nicht bei jeder Kleinigkeit eine DB-Abfrage machen zu müssen. Beispielsweise könnte eine einzelne Seite mit einer Artikelliste folgende Informationen anfordern (in eckigen Klammern stehen die Tabellen, die zusätzlich zur Tabelle "sets" benötigt werden):

Set 1, "Kategorien" (mit Hierarchie)
- Abfrage allgemein: alle Tags des Sets, als Liste mit Hierarchie [tags, tree, relations(für Anzahl)]
- Abfrage pro Artikel: dem Item(Artikel) zugewiesene Tags(Kategorien) [items, relations, tags]
Set 2, "Tags" (ohne Hierarchie)
- Abfrage allgemein: Tag-Cloud, alle Tags des Sets ohne Hierarchie [tags, relations(für Anzahl)]
- Abfrage pro Artikel: dem Item(Artikel) zugewiesene Tags(Begriffe) [items, relations, tags]

Die Beziehung item->tags wird also i.d.R. für einen Artikel gebraucht, tag->items für die Suche/Filterung von Artikeln. Die Methoden der tags-Klasse erwarten als Argumente den/die Tag-Namen oder Item-Namen (z.B. get_tags($item_name)).
Nun zu den eigentlichen Problemen:

Da Arrays einen gewissen Overhead haben frage ich mich, wie schnell ich mit diesem Konstrukt an die Grenzen des Speichers stoße, und in welchem Rahmen ich auf array_search() oder zusätzliche DB-Abfragen ausweichen sollte.
Wie oben geschrieben sollen die Tabellen erst bei Bedarf abgefragt werden, dann aber für alle vermerkten Sets. Würde bedeuten, dass am Anfang des Scripts/Templates beide Sets registriert werden und weitere Abfragen immer prophylaktisch für beide Sets erfolgen.

Danke schon mal im Voraus für eure Gedanken und Mühe.

Hier schließlich noch eine Liste der Tabellen ("set_id" kommt in jeder vor, um Joins/Subqueries zu vermeiden):

Code:

Tabelle `sets`
            `set_id`  smallint unsigned not null auto_increment,
          `set_name`  varchar(64) not null,
   `option_use_tree`  boolean not null default true,
   `option_auto_add`  boolean not null default true,
`option_auto_delete`  boolean not null default true,
primary key(`set_id`),
unique key(`set_name`)

Tabelle `tags`
  `tag_id`  smallint unsigned not null auto_increment,
  `set_id`  smallint unsigned not null,
`tag_name`  varchar(64) not null,
primary key(`tag_id`),
unique key(`set_id`, `tag_name`)


Tabelle `items`
   `set_id`  smallint unsigned not null,
  `item_id`  smallint unsigned not null auto_increment,
`item_name`  varchar(64) not null,
primary key(`item_id`),
unique key(`set_id`, `item_name`)


Tabelle `relations`
 `set_id`  smallint unsigned not null,
 `tag_id`  smallint unsigned not null,
`item_id`  smallint unsigned not null,
primary key(`tag_id`, `item_id`)

Tabelle `tree`
  `set_id`  smallint unsigned not null,
  `tag_id`  smallint unsigned not null,
`child_id`  smallint unsigned not null,
primary key(`set_id`, `tag_id`, `item_id`)

Gesundes Neues und bestes Grüße
Fabian

nikosch · 05.01.2009, 17:52

Kannst Du die Bedutung von Schlagwort-Sets und Schlagwort-Hierarchien kurz erläutern?

ciss · 05.01.2009, 18:37

Ein Set ist ein Paket von Schlagworten mit eigenen Einstellungen, wie z.B. ob ein Baum genutzt weden soll, ob neue Schlagworte automatisch ergänzt und ungenutzte automatisch gelöscht werden. Jedes Set ist in sich abgeschlossen und hat keinen Bezug zu anderen Sets.
Die Hierarchie gruppiert die Schlagworte, z.B. können dem Schlagwort "Tiere" die Schlagworte "Fische" und "Vögel" untergeordnet sein, diesen wiederum "Hering", "Lachs" usw.
Fragt man nun nach "Tiere", werden die untergeordneten Schlagworte in die Abfrage mit einbezogen.

nikosch · 05.01.2009, 18:59

Wuiuiui, schöne Idee. Aber komplexes System.

Vorschlag: Ich würde von den Items als Bedutungsträger ausgehen, für diese Objekt anlegen und darin Objekte für die zugeordneten Tags. Diesen wiederum Gruppierungen und Hierarchien zuordnen und das ganze sinnvoll cachen - je nach Bedarf das Item oder nur die Tag-Objektstruktur.

erc · 05.01.2009, 19:07

Zitat:

Zitat von ciss

Nun zu den eigentlichen Problemen:

Da Arrays einen gewissen Overhead haben frage ich mich, wie schnell ich mit diesem Konstrukt an die Grenzen des Speichers stoße, und in welchem Rahmen ich auf array_search() oder zusätzliche DB-Abfragen ausweichen sollte.
Wie oben geschrieben sollen die Tabellen erst bei Bedarf abgefragt werden, dann aber für alle vermerkten Sets. Würde bedeuten, dass am Anfang des Scripts/Templates beide Sets registriert werden und weitere Abfragen immer prophylaktisch für beide Sets erfolgen.

1. Test es aus. Für ein paar hundet Tags und ein paar tausend Beziehungen ist das kein Problem, aber irgendwo gibts da Grenzen und ob ein Array sinnvoll ist der mehrere Megabyte mit unnützen Daten hält ist die andere Frage. Ich seh jetzt nicht wirklich einen Grund das ganze nicht mit SQL zu machen. Wenn ichs richtig überblickt habe kann man alle Informationen mit einem Query auslesen. (dazu müssten die tabelle tree angepasst werden)
2. ist das ein Problem?

nikosch · 05.01.2009, 19:11

Gerade diese Gruppierungsgeschichte kann man vermutlich mit keiner Lösung so effizient lösen wie mit SQL.

erc · 05.01.2009, 19:31

Zitat:

Zitat von nikosch

Gerade diese Gruppierungsgeschichte kann man vermutlich mit keiner Lösung so effizient lösen wie mit SQL.

Mit nested trees lässt sich sowas recht performant umsetzen.

nikosch · 05.01.2009, 19:32

Zitat:

Mit nested trees lässt sich sowas recht performant umsetzen.

Glaube ich eher nicht, weil das Wesen von Tags die multiple Zugehörigkeit zu einem Kontext ist. Ein Baum ist dagegen linear strukturiert.

erc · 05.01.2009, 19:53

Zitat:

Zitat von nikosch

Glaube ich eher nicht, weil das Wesen von Tags die multiple Zugehörigkeit zu einem Kontext ist. Ein Baum ist dagegen linear strukturiert.

Hab ich was falsch verstanden? Ich hab es so verstanden das deine Tags selbst als Baum strukturiert sind.

Code:

Tier
   Fisch
      Goldfisch
      Karpfen

Der Tag Baum selbst hat doch aber nix mit mit der zuordnung Artikel/Tag zu tun? z.B. Ich ordne jetzt den Tag Goldfisch ein oder mehreren Artikeln zu. Mit einem nested set hab ich jetzt die mögichkeit mit einem Query alle Artikel rauszusuchen die z.b. den Tag Fisch oder deren Kindern (Goldfisch, Karpfen) angehöhren.

nikosch · 05.01.2009, 20:01

Ja. Aber "Fisch" könnte gleichzeitig auch "Wasser" oder "Hauptgang" (i.S.v. Mittagstisch) als Elterntag erhalten (wobei letzteres dann bereits das Kontextproblem beim Taggen demonstriert). So würde ich das jedenfalls anlegen. Eine Baumstruktur für Tags irgendwie ad absurdum. Selbst wenn es nur Gruppen sind. Bspw. delicious setzt Gruppierung auch mehrfach um, dafür aber nur in einer Tiefenstaffelung.

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

Ähnliche Themen
Thema	Autor	Forum	Antworten	Letzter Beitrag
Autologin mit Cookie, wie? Beste Lösung?		PHP-Fortgeschrittene	17	16.02.2006 14:03
Ist dieses die beste Lösung?	Mano	PHP Tipps 2004	6	10.06.2004 13:55

05.01.2009, 17:45
ciss Neuer Benutzer Registriert seit: 02.12.2008 Beiträge: 16	Tags-Verwaltung: beste Lösung (DB/Speicher)? Hi, ich zerbreche mir gerade den Kopf über eine ausgewogene Lösung für den DB-Zugriff einer Schlagwort-Verwaltung. Aufgebaut ist das ganze so: Schlagwort-Sets (Tabelle "sets") Schlagworte ("Tags", Tabelle "tags") Verschlagwortete Objekte ("Items", Tabelle "items") Schlagwort-Hierarchie (Tabelle "tree") Schlagwort-Objekt-Beziehungen (Tabelle "relations") Die Tabellen sind weiter unten aufgelistet. Ich habe eine Klasse "tags_db", die die DB-Zugriffe verwalten und auf ein Minimum reduzieren soll. Diese holt sich bei der ersten Instantiierung die Tabelle "sets" aus der DB und speichert sie statisch, alle späteren Abfragen sollen bei Bedarf erfolgen und ebenfalls statisch gespeichert werden. Der Array dafür hat folgende Struktur: Code: $SETS = array( set_name => array( 'tags' => array( tag_id => tag_name, tag_id => tag_name, ...), 'items' => array( item_id => item_name, item_id => item_name, ...), 'tag_relations' => array( tag_id => array( item_id, item_id, ...), tag_id => array( item_id, item_id, ...), ...), 'item_relations' => array( item_id => array( tag_id, tag_id, ...), item_id => array( tag_id, tag_id, ...), ...), 'tree' => array( tag_id => array( tag_id, tag_id, ...), tag_id => array( tag_id, tag_id, ...), ...), 'options' => array( option => wert, option => wert, ...), ), set_name => ... ); Ich hatte diese Struktur gewählt um so wenig wie möglich mit array_search arbeiten und gleichzeitig nicht bei jeder Kleinigkeit eine DB-Abfrage machen zu müssen. Beispielsweise könnte eine einzelne Seite mit einer Artikelliste folgende Informationen anfordern (in eckigen Klammern stehen die Tabellen, die zusätzlich zur Tabelle "sets" benötigt werden): Set 1, "Kategorien" (mit Hierarchie) Abfrage allgemein: alle Tags des Sets, als Liste mit Hierarchie [tags, tree, relations(für Anzahl)] Abfrage pro Artikel: dem Item(Artikel) zugewiesene Tags(Kategorien) [items, relations, tags] Set 2, "Tags" (ohne Hierarchie) Abfrage allgemein: Tag-Cloud, alle Tags des Sets ohne Hierarchie [tags, relations(für Anzahl)] Abfrage pro Artikel: dem Item(Artikel) zugewiesene Tags(Begriffe) [items, relations, tags] Die Beziehung item->tags wird also i.d.R. für einen Artikel gebraucht, tag->items für die Suche/Filterung von Artikeln. Die Methoden der tags-Klasse erwarten als Argumente den/die Tag-Namen oder Item-Namen (z.B. get_tags($item_name)). Nun zu den eigentlichen Problemen: Da Arrays einen gewissen Overhead haben frage ich mich, wie schnell ich mit diesem Konstrukt an die Grenzen des Speichers stoße, und in welchem Rahmen ich auf array_search() oder zusätzliche DB-Abfragen ausweichen sollte. Wie oben geschrieben sollen die Tabellen erst bei Bedarf abgefragt werden, dann aber für alle vermerkten Sets. Würde bedeuten, dass am Anfang des Scripts/Templates beide Sets registriert werden und weitere Abfragen immer prophylaktisch für beide Sets erfolgen. Danke schon mal im Voraus für eure Gedanken und Mühe. Hier schließlich noch eine Liste der Tabellen ("set_id" kommt in jeder vor, um Joins/Subqueries zu vermeiden): Code: Tabelle `sets` `set_id` smallint unsigned not null auto_increment, `set_name` varchar(64) not null, `option_use_tree` boolean not null default true, `option_auto_add` boolean not null default true, `option_auto_delete` boolean not null default true, primary key(`set_id`), unique key(`set_name`) Tabelle `tags` `tag_id` smallint unsigned not null auto_increment, `set_id` smallint unsigned not null, `tag_name` varchar(64) not null, primary key(`tag_id`), unique key(`set_id`, `tag_name`) Tabelle `items` `set_id` smallint unsigned not null, `item_id` smallint unsigned not null auto_increment, `item_name` varchar(64) not null, primary key(`item_id`), unique key(`set_id`, `item_name`) Tabelle `relations` `set_id` smallint unsigned not null, `tag_id` smallint unsigned not null, `item_id` smallint unsigned not null, primary key(`tag_id`, `item_id`) Tabelle `tree` `set_id` smallint unsigned not null, `tag_id` smallint unsigned not null, `child_id` smallint unsigned not null, primary key(`set_id`, `tag_id`, `item_id`) Gesundes Neues und bestes Grüße Fabian


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

05.01.2009, 17:52
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.255 PHP-Kenntnisse: Fortgeschritten	Kannst Du die Bedutung von Schlagwort-Sets und Schlagwort-Hierarchien kurz erläutern? __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

05.01.2009, 18:37
ciss Neuer Benutzer Registriert seit: 02.12.2008 Beiträge: 16	Ein Set ist ein Paket von Schlagworten mit eigenen Einstellungen, wie z.B. ob ein Baum genutzt weden soll, ob neue Schlagworte automatisch ergänzt und ungenutzte automatisch gelöscht werden. Jedes Set ist in sich abgeschlossen und hat keinen Bezug zu anderen Sets. Die Hierarchie gruppiert die Schlagworte, z.B. können dem Schlagwort "Tiere" die Schlagworte "Fische" und "Vögel" untergeordnet sein, diesen wiederum "Hering", "Lachs" usw. Fragt man nun nach "Tiere", werden die untergeordneten Schlagworte in die Abfrage mit einbezogen.

05.01.2009, 18:59
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.255 PHP-Kenntnisse: Fortgeschritten	Wuiuiui, schöne Idee. Aber komplexes System. Vorschlag: Ich würde von den Items als Bedutungsträger ausgehen, für diese Objekt anlegen und darin Objekte für die zugeordneten Tags. Diesen wiederum Gruppierungen und Hierarchien zuordnen und das ganze sinnvoll cachen - je nach Bedarf das Item oder nur die Tag-Objektstruktur. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

05.01.2009, 19:11
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.255 PHP-Kenntnisse: Fortgeschritten	Gerade diese Gruppierungsgeschichte kann man vermutlich mit keiner Lösung so effizient lösen wie mit SQL. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --

05.01.2009, 20:01
nikosch moderatives Dielektrikum Registriert seit: 21.05.2008 Beiträge: 34.255 PHP-Kenntnisse: Fortgeschritten	Ja. Aber "Fisch" könnte gleichzeitig auch "Wasser" oder "Hauptgang" (i.S.v. Mittagstisch) als Elterntag erhalten (wobei letzteres dann bereits das Kontextproblem beim Taggen demonstriert). So würde ich das jedenfalls anlegen. Eine Baumstruktur für Tags irgendwie ad absurdum. Selbst wenn es nur Gruppen sind. Bspw. delicious setzt Gruppierung auch mehrfach um, dafür aber nur in einer Tiefenstaffelung. __________________ -- One pixel is still too big. Please make it smaller. ASAP. Initiative Mittelstand. Die wichtigste Gestaltungsregel im Screendesign ist Pi mal Daumen des Arbeitgebers. --