Tagging Konzept

André Griepenburg

André Griepenburg

Legendäres Mitglied
Hallo,

mache mir derzeit über das eine oder andere als "Web2.0" verschriene Feature Gedanken, dazu gehört auch das "Tagging".
Nun frage ich mich jedoch, wie ihr das gelöst habt:

Habt ihr alles in 1 Tabelle in der Datenbank?
Wenn ja, wie sehen eure Felder aus und wie unterscheidet ihr Content?


Mir geht es hier nicht um das reine Forentagging, sondern um die Mischformen wo z.B. Forenthemen, Fotos und Kommentare getaggt werden.
Würde mich über eure Beiträge freuen...


Gruß,
André
 
Ich würde es wohl über eine n:m Beziehung lösen:

CODE +----+-----+
| id | ... |
| -- |     |
+----+-----+
   | n
   \_________
             \
              | 1
+--------+-------------+
| tag_id | beitrags_id |
| ------ | ----------- |
+--------+-------------+
  | 1
  |
  | n
+----+----------+
| id | tag_name |
| -- |          |
+----+----------+
 
Warum n:m?

Ich gehe über eine 1:n - Beziehung:

x;y;ThemenID - ThemenID;TagBezeichner

Spart mir eine Tabelle.
Wobei meine Taggintabelle noch als Drittes ein numerisches Feld für die Kategorie enthält um eben Themenbereiche wie Foreneintrag, Userprofil, Galleriebild und ähnliches bestimmen zu können.
 
QUOTE (TSc @ Sa 30.12.2006, 23:32)Warum n:m?

Ich gehe über eine 1:n - Beziehung:

x;y;ThemenID - ThemenID;TagBezeichner [...]

Eine Tag-Bezeichnung kann mehreren Beiträgen zugeordnet werden und mehrere Beiträge können einer Tag-Bezeichnung zugeordnet werden! Darum eine n:m Beziehung, eine 1:n Beziehung schafft entweder Redundanzen, oder mit ihr ist es nur möglich eine Tagbezeichnung zu zuweisen (bzw. einer Tagbezeichnung nur einem Thema).

Das sind eigentlich Grundlagen der Strukturierung von Datenbanken (Stichwort: Normalisierung).



QUOTE (TSc @ Sa 30.12.2006, 23:32)[...] Spart mir eine Tabelle. [...]

Und es geht dabei nicht darum eine Tabelle zu sparen oder nicht, sondern Speicherplatz zu sparen und somit ggf. auch die Preformence zu sichern.
 
Genau das, nämlich das sparen von Speicherplatz und damit Performance, hatte ich im Sinn als ich vermeiden wollte ein weiteres ID-Feld zu nutzen.

Das in meiner Lösung redundanzen vorkommen können ist richtig, was aber daran liegt das ich da halbe Sachen aufgeschrieben habe.
Zur Erklärung: Ich nutze die Tags gleichzeitg als Lesezeichen der Nutzer. Das bedeutet jedem Tag ist ein kombinierter Primärschlüssel aus BeitragsID und UserID zugeordnet was die Redundanzen in den Tag-Namen leider nötig macht falls mehrere User das gleiche Wort als Lesezeichen nutzen und gegebenenfalls editieren wollen.

Daher wäre für ein reines, userunabhängiges Tagging deine Lösung die Bessere.

Eins verstehe ich allerdings noch nicht:
Ich gehe davon aus das in der ersten Tabelle, der Beitragstabelle, die BeitragsID nicht n-mal vorkommen kann, da sie meiner Meinung nach normalerweise ein Primärschlüßel sein müßte.
Mein Problem ist das ich grade nicht nach vollziehen kann wie du darauf kommst das eine BeitragsID n mal in der Beitragstabelle vorkommen kann?
Daher müste von Beitragstabelle zu Zwischentabelle eine 1:n-Beziehung herschen und nicht eine n:1-Beziehung, oder?

Ist nicht bös gemeint, ich würde deinen Gedankengang nur gern nachvollziehen können...

Und die Regeln zu Normalisierung und DeNormalisierung sind mir durchaus geläufig.
wink.gif
 
QUOTE (TSc @ So 31.12.2006, 1:30)[...]
Mein Problem ist das ich grade nicht nach vollziehen kann wie du darauf kommst das eine BeitragsID n mal in der Beitragstabelle vorkommen kann?
Daher müste von Beitragstabelle zu Zwischentabelle eine 1:n-Beziehung herschen und nicht eine n:1-Beziehung, oder?
[...]

Vielleicht liegt hier auch einfach ein Missverständnis innerhalb der Schreibweise vor, würde ich die mittelere Tabelle weglassen würde dort einfach n:m stehen.

Eine BeitragsID kann nur einmal in der Beitragstabelle vorkommen (drum ist es ja schließlich auch der Primärschlüssel), doch die BeitragsID kann n mal in der Beziehungstabelle stehen. Die Kombination zwischen BeitragsID und TagID aus der Beziehungstabelle kann jedoch nur einmal der Beitragstabelle zugeordnet werden.

Die Beschriftung bezieht sich also auf das gegenüberliegende Ende der Verbindungsliniene, wie es beim UML auch der Fall ist.


CODE +-------+
|betrag |
+-------+
   | (1,n)
   |
   |
-------------
| gehört an |
-------------
   |
   |
   | (0,n)
+-----+
| tag |
+-----+




Meinst Du sowas?:

CODE +----+-----+
| id | ... |
| -- |     |
+----+-----+
  | n
  \_________________________
                            \
                             | 1
+--------+-------------+-------------+
| tag_id | benutzer_id | beitrags_id |
| ------ | ----------- | ----------- |
+--------+-------------+-------------+
  | 1
  |
  | n
+----+-------------+----------+
|    |             |          |
| id | benutzer_id | tag_name |
| -- | ----------- |          |
+----+-------------+----------+




Das könnte man so erweitern (mal komplett ausgeschrieben; Die Fremdschlüssel aus den Beziehungstabellen beinhalten natürlich ein Unique, so dass jede Komination nur einmal auftreten kann):

CODE beitrag
+----+-----+
| id | ... |
| -- |     |
+----+-----+
  | n
  \________________________
                           \
beitrag_tag_benutzer       | 1
+----+-----------------+------------+
| id | tag_benutzer_id | beitrag_id |
| -- | - - - - - - - - | - - - - -  |
+----+-----------------+------------+
        | 1
  ______/
 /
 | n    tag_benutzer
+----+-------------+--------+
|    |             |        |
| id | benutzer_id | tag_id |
| -- | - - - - - - | - - -  |
+----+-------------+--------+
         | 1          | 1
   ______/            |
  /                   |
  | n  benutzer       | n  tag
+----+-----+        +----+-----+
| id | ... |        | id | ... |
| -- |     |        | -- |     |
+----+-----+        +----+-----+



Wobei man hier überlegen kann, ob sich der Programmieraufwand überhaupt noch lohnt und was wirkt sich hier wohl wirklich besser auf die Preformance aus. So das ich mir diese Alternative noch vorstellen könnte:

CODE beitrag
+----+-----+
| id | ... |
| -- |     |
+----+-----+
  | n
  \________________________
                           \
beitrag_tag_benutzer        | 1
+----+-------------+------------+--------+
| id | benutzer_id | beitrag_id | tag_id |
| -- | - - - - - - | - - - - -  | - - -  |
+----+-------------+------------+--------+
         | 1                      | 1
   ______/                ________/
  /                      /
  | n   benutzer         | n   tag
+----+-----+            +----+-----+
| id | ... |            | id | ... |
| -- |     |            | -- |     |
+----+-----+            +----+-----+
 
Wenn ich mir das so anschaue lag das Problem glaub ich das ich dein 1:n als n:1 gelesen habe und mich daher natürlich fragte wie das klappen soll.
smile.gif


Ein klassisches Missverständniss der Notation.
 
Hab mir die Links hier im Forum und auf Wikipedia mal angeschaut, aber das hat mich im Verständnis der TagClouds noch nicht sonderlich weitergebracht.

Wo bitte liegt der Sinn in sowas? Benutzt ihr sowas wirklich wenn ihr als Gast auf einer Seite seid? Sieht zwar toll aus, aber draufklicken tu ich zumindest eigentlich nie ..
 
QUOTE (Yosh @ Di 2.1.2007, 11:30) Hab mir die Links hier im Forum und auf Wikipedia mal angeschaut, aber das hat mich im Verständnis der TagClouds noch nicht sonderlich weitergebracht.

Wo bitte liegt der Sinn in sowas? Benutzt ihr sowas wirklich wenn ihr als Gast auf einer Seite seid? Sieht zwar toll aus, aber draufklicken tu ich zumindest eigentlich nie ..

Hallo,

also für mich liegt der Sinn im Tagging weniger in den Tag-Clouds als mehr in der interaktiven Verlinkung von Content untereinander.
Sei es nun textueller Content (in Form von Forenbeiträgen, Berichten, Kommentaren etc.) oder aber Multimedialer (Fotos, Videos, etc.).
Denke das hat eine kräftige Wirkung und wird auch viel genutzt.


Tag Clouds an sich habe ich noch nie genutzt ^^
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben