Diese Tabelle normalisieren?

Question

Ich erstelle eine App für soziale Lesezeichen. Ich habe ein Re-Thought der DB-Design in der Mitte der Entwicklung.

Soll ich die Lesezeichentabelle normalisieren und die Markierungsspalten, die ich habe, in eine separate Tabelle entfernen? Ich habe 10 Tags pro Lesezeichen und daher 10 Spalten pro Datensatz (pro Lesezeichen).

Es scheint mir, dass das Brechen der Tabelle in zwei würde nur bedeuten, ich müsste eine Verknüpfung zu tun, aber die Art und Weise, die ich derzeit haben, ist eine gerade auswählen - aber die Tabelle fühlt sich nicht richtig ...?

Danke an alle

Update

Aktuelle Tabellenstruktur:

CREATE TABLE IF NOT EXISTS `bookmarks` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `title` char(250) NOT NULL,
  `link` text NOT NULL,
  `keyword_1` char(250) NOT NULL,
  `keyword_2` char(250) NOT NULL,
  `keyword_3` char(250) NOT NULL,
  `keyword_4` char(250) NOT NULL,
  `keyword_5` char(250) NOT NULL,
  `keyword_6` char(250) NOT NULL,
  `keyword_7` char(250) NOT NULL,
  `keyword_8` char(250) NOT NULL,
  `keyword_9` char(250) NOT NULL,
  `keyword_10` char(250) NOT NULL,
  `date_added` datetime NOT NULL,
  `privacy_type` int(11) NOT NULL,
  `user_id` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=MyISAM  DEFAULT CHARSET=latin1 AUTO_INCREMENT=68 ;

Ein Lesezeichen gehört zu einem Benutzer, ein Tag gehört zu einem Lesezeichen. Sollte ich also die user_id zur Tabelle tags hinzufügen?

Eine neue verwandte Frage:

Wie würden Sie nach einem Tag suchen und das Lesezeichen zurückgeben?

Schön, ein Beispiel für eine SQL-Abfrage zu sehen. Ich hoffe auf etwas Effizientes, da mir derzeit nichts Anständiges einfällt, außer einem LIKE-Test für jede Schlüsselwortspalte!

Answer 1

Planen Sie für die Zukunft im Moment sind sie nur Tags, aber sie können am Ende mit Eigenschaften oder Attributen, die auf dem Tag bauen. Wenn Sie sie separat speichern würden, wäre das viel einfacher, eine Verknüpfung würde die Daten zusammenführen. Wenn Sie sie nur in einer Tabelle verwenden und dieser Tabelle etwas hinzufügen müssen, wird das zu einem Albtraum. Normalisieren Sie die Daten, indem Sie eine eigene Entitätentabelle einrichten. Das ist wie gutes OOP, viel mehr Arbeit im Vorfeld, aber am Ende zahlt es sich aus :).

Answer 2

Ich denke, dass die Normalisierung der Tags in eine eigene Tabelle zu weniger Codezeilen führt und eine Erweiterung der Anzahl der Tags leichter möglich ist, ohne dass der Code überarbeitet werden muss.

Auf diese Weise können Sie auch die Tags unabhängig voneinander und als Gruppe abfragen, z. B. die zehn beliebtesten Tags ermitteln usw.

SELECT key_word, count(bookmark_id) AS tag_frequency
FROM tags
GROUP BY key_word
ORDER BY count(bookmark_id) DESC LIMIT 10

Aus objektorientierter Sicht bedeutet die Normalisierung der Tags in eine eigene Tabelle, dass tag1, tag2 usw. nicht mehr Attribute von bookmark sind, sondern dass tags ein Attribut von bookmark wird, das eine Sammlung von tags ist.

Sie werden wahrscheinlich tatsächlich weniger Codezeilen schreiben, obwohl Sie die Dinge etwas anders handhaben werden.

Zum Beispiel werden Sie zunächst das Lesezeichen und seine Attribute nachschlagen. Wenn Sie dann eine Liste von Tags für das Lesezeichen erhalten möchten, führen Sie eine weitere Abfrage in der Tabelle Tags durch. Sie werden wahrscheinlich keine Verknüpfung für die Suche in dieser Richtung durchführen.

Sie können dann einfach die Liste der Tags durchgehen und für jeden Tag dieselbe Verarbeitung durchführen, anstatt für jeden Tag mehrere Codezeilen zu schreiben.

Sie werden jedoch eine Verknüpfung verwenden, um ein Lesezeichen für ein Tag zu finden:

SELECT bookmarks.id, bookmarks.title
FROM tags
JOIN bookmarks ON bookmarks.id = tag.bookmark_id
WHERE tags.key_word = ?

Natürlich kann dies mehr als einen Datensatz ergeben.

Answer 3

Ich würde es normalisieren. Wenn Sie nicht bei jedem Lesezeichen Tags verwenden, würde das die Leistung steigern. Und das würde Ihnen etwas mehr Flexibilität geben, zum Beispiel eine Tagg-Wolke einrichten und einfach alle verschiedenen Tags abrufen.