Tags bzw. Schlagwörter in Datenbank speichern

    Hallo!

    Das ist eine Frage, die mich jetzt schon einige Zeit beschäftigt... Wie sieht das Datenbankdesign einer Software/Onlinedinst aus, die Tags zu Links, Photos, usw. speichert?

    Die einzige Lösung die mir einfällt, ist eigentlich nur folgende:

    2 Tabellen, z.B für Links mit Tags:

    Links: {id, Title, URL}
    LinkTags: {LinkId, Tag}

    Natürlich könnte ich auch die URL als Schlüssel nehmen, aber um das gehts ja nicht (außerdem würde die URL viel mehr Platz brauchen als ne ID)...

    Ist das die beste Lösung, oder fällt wem eine gscheitere ein? Find das schaut so unelegant aus...

    Vielleicht überseh ich irgendein zusätzliches 'Feature' , dass man bei Tags noch beachten sollte, kennt jemand nen guten Artikel oder Tips zu dem Thema?

    mfg Huzi

    Ich würd da eine Relation für die Tags einführen, damit du über diese Relation festlegen kannst, welche Tags verwendet werden dürfen. Außerdem kannst du dann effizient abfragen, welche Tags es gibt, weil du nur die Relation "Tags" abfragen musst und nicht sowas wie "SELECT DISTINCT Tag" über die Relation "LinkTags" machen musst.

    In einem ER-Diagramm wären das also zwei Entitäten "Links" und "Tags" mit einer M:N-Beziehung dazwischen.

    Zitat von huzi

    Ist DISTINCT leicht so langsam bzw. aufwendig? Oder ist es einfach nur unschön?

    Bei großer Anzahl von Datensätzen ist Duplikatelimination recht langsam.

    Zitat von huzi

    Ist es dann auch noch gscheit tags eine Id zu geben?

    Kommt auf die Bezeichnung der Tags an und ist in einem gewissen Maße Geschmackssache. Anstelle eines Tagnamens, der 1000 Zeichen lang sein kann, würd ich wohl eine ID einführen, genauso statt eines zusammengesetzten, womöglich aus einer ganzen Handvoll von Attributen bestehenden Primärschlüssels. Sind die Tagnamen aber zum Beispiel auf fünf Zeichen beschränkt, bieten sie sich natürlich eher als Primärschlüssel an.

    Zitat von Plantschkuh!

    Ich bin kein Datenbank-Mensch, aber ich hab das vage Gefühl, hashbasiert würde das schnell gehen.

    Nja den Hash müsste man vermutlich auch eigens für das distinct erzeugen, da es ja von der Projektion abhängt welche Spalten/Werte verglichen werden.

    Denke das Problem liegt daran, dass beim distinct die Werte Felder nicht indiziert sind (wie z.B.: bei Schlüsseln) und dass es im Optimierungsbaum nicht nach unten verschoben werden kann (wie z.B.: bei einer Selektion) sondern immer an oberster Stelle steht.

    Das es mit distinct bei größeren Mengen saulangsam wird, konnte ich auch schon mal hautnah in der Praxis miterleben (und wurde auch "belehrt" [das merkt man sich meistens ;)]).

    Bin aber auch kein DB Mensch, also nur Vermutungen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden