Kann mir jemand verraten wie man am klügsten eine „Tag(s)“ Datenbank anlegt?

Mein Überlegung wäre einfach eine Tabelle, mit 3 Spalten

ID
TAG
ID_CONTENT (ID des umschriebenen zb. Artikels oder Bild)

Aber vielleicht liege ich auch total falsch, würde mich um etwas Anregung freuen um keine Fehler zu machen.

Mein Vorschlag: 2 Tabellen

1. Tabelle: Tags
TAG-ID | Tag

2. Tabelle: Tags2Content
ID | TAG-ID | CONTENT-ID

Dann hast du keine Dopplungen der Tags (also der Strings) bzw. wenn du ein Tag umbenennen willst musst du das nur einmal tun.

edit: Wenn ein Content mehrere Tags hat wird dieser mehrfach in die Tabelle Tag2Content geschrieben.

Stimmt, ist die bessere Lösung. Danke.

Braucht die zweite Tabelle eine eigene ID?

marx schrieb am 17.03.09, 14:39 Uhr:

Braucht die zweite Tabelle eine eigene ID?

Nein, mit einer Extra-ID ist es Datenbanktechnisch gesehen sogar falsch.

Stimmt die ist unnötig.

Gut. Kam mir komisch vor.

mente schrieb am 17.03.09, 14:54 Uhr:

marx schrieb am 17.03.09, 14:39 Uhr:

Braucht die zweite Tabelle eine eigene ID?

Nein, mit einer Extra-ID ist es Datenbanktechnisch gesehen sogar falsch.

Das habe ich mich auch grad beim anlegen gefragt, danke.

mente schrieb am 17.03.09, 14:54 Uhr:

Nein, mit einer Extra-ID ist es Datenbanktechnisch gesehen sogar falsch.

wieso meinst du, dass das unbedingt falsch wäre?

Weil es dann nicht der Normalisierung entspricht, so wie sie in der Theorie gelehrt wird. In der Praxis kann das natürlich immer anders aussehen.

Sowas soll durch Normalisierung unterbunden werden:

| ID | Tag-ID | Content-ID |
| 1 | 5 | 34 |
| 2 | 5 | 34 |

Wenn die aber ID wegfällt, ist so eine Dopplung technisch gar nicht erst möglich, weil es sich bei Tag-ID und Content-ID um einen doppelten Primärschlüssel handelt. Alles andere führt zu inkonsistenten Daten.

das stimmt natürlich. wobei man dabei wohl davon ausgeht, dass bilder und sonstige inhalte eine unique id haben, also in der selben tabelle stehen, oder das sonst wie sichergestellt wird... was vermutlich nicht so häufig vorkommt...

Dominic schrieb am 17.03.09, 16:51 Uhr:

das stimmt natürlich. wobei man dabei wohl davon ausgeht, dass bilder und sonstige inhalte eine unique id haben, also in der selben tabelle stehen, oder das sonst wie sichergestellt wird... was vermutlich nicht so häufig vorkommt...

Darum achtet man auf sowas, wenn man heute ein neues System aufstellt. In der Praxis fällt die Datenkonsistenz vo allem aus Performancegründen häufig weg.

Dominic schrieb am 17.03.09, 16:51 Uhr:

das stimmt natürlich. wobei man dabei wohl davon ausgeht, dass bilder und sonstige inhalte eine unique id haben, also in der selben tabelle stehen, oder das sonst wie sichergestellt wird... was vermutlich nicht so häufig vorkommt...

Der einzige Sinn dieser Tabelle ist doch die Verknüpfung zweier Tabellen und dafür wählt man zwei einzigartige Inhalte, die idealerweise auch noch jeweils Schlüssel sind, also unique. Zumindest mache ich als Laie das so, denn damit kann man einige Fehler umgehen. Bei komplexeren tabellen ist das natürlich nicht mehr so einfach, aber in diesem Fall…

marx schrieb am 17.03.09, 17:40 Uhr:

Dominic schrieb am 17.03.09, 16:51 Uhr:

das stimmt natürlich. wobei man dabei wohl davon ausgeht, dass bilder und sonstige inhalte eine unique id haben, also in der selben tabelle stehen, oder das sonst wie sichergestellt wird... was vermutlich nicht so häufig vorkommt...

Der einzige Sinn dieser Tabelle ist doch die Verknüpfung zweier Tabellen und dafür wählt man zwei einzigartige Inhalte, die idealerweise auch noch jeweils Schlüssel sind, also unique. Zumindest mache ich als Laie das so, denn damit kann man einige Fehler umgehen. Bei komplexeren tabellen ist das natürlich nicht mehr so einfach, aber in diesem Fall…

genau.

in diesem fall hieß es im ausgangsposting:
> (ID des umschriebenen zb. Artikels oder Bild)

was erstmal einfach verschiedene interpretationen zulässt und vielleicht nicht die theoretisch simpelste. was auch nicht heißen soll, dass diese falsch wäre.