Progettazione del database SQL consigliata per tag o tag [chiuso]

Ho sentito parlare di alcuni modi per implementare la codifica; usando una tabella di mappatura tra TagID e ItemID (per me ha senso, ma si adatta?), aggiungendo un numero fisso di possibili colonne TagID a ItemID (sembra una cattiva idea), Mantenere i tag in una colonna di testo che è separato da virgola (suoni pazzo ma potrebbe funzionare). Ho persino sentito qualcuno raccomandare una matrice sparsa, ma come fanno i nomi dei tag a crescere con grazia?

Mi sto perdendo una best practice per i tag?

Tre tabelle (una per la memorizzazione di tutti gli elementi, una per tutti i tag e una per la relazione tra i due), opportunamente indicizzate, con chiavi esterne impostate in esecuzione su un database adeguato, dovrebbero funzionare bene e adattarsi correttamente.

Table: Item
Columns: ItemID, Title, Content

Table: Tag
Columns: TagID, Title

Table: ItemTag
Columns: ItemID, TagID

Normalmente concordo con Yaakov Ellis ma in questo caso speciale esiste un'altra soluzione praticabile:

Usa due tabelle:

Table: Item
Columns: ItemID, Title, Content
Indexes: ItemID

Table: Tag
Columns: ItemID, Title
Indexes: ItemId, Title

Questo ha alcuni importanti vantaggi:

Innanzitutto rende lo sviluppo molto più semplice: nella soluzione a tre tabelle per l'inserimento e l'aggiornamento di itemte devi cercare la Tagtabella per vedere se ci sono già voci. Quindi devi unirti a loro con nuovi. Questo non è un compito banale.

Quindi rende le query più semplici (e forse più veloci). Esistono tre query di database principali che verranno eseguite: Output tutto Tagsper uno Item, disegnare un Tag-Cloud e selezionare tutti gli elementi per un titolo Tag.

Tutti i tag per un oggetto:

3-Table:

SELECT Tag.Title 
  FROM Tag 
  JOIN ItemTag ON Tag.TagID = ItemTag.TagID
 WHERE ItemTag.ItemID = :id

2-Tabella:

SELECT Tag.Title
FROM Tag
WHERE Tag.ItemID = :id

Tag-Cloud:

3-Table:

SELECT Tag.Title, count(*)
  FROM Tag
  JOIN ItemTag ON Tag.TagID = ItemTag.TagID
 GROUP BY Tag.Title

2-Tabella:

SELECT Tag.Title, count(*)
  FROM Tag
 GROUP BY Tag.Title

Articoli per un tag:

3-Table:

SELECT Item.*
  FROM Item
  JOIN ItemTag ON Item.ItemID = ItemTag.ItemID
  JOIN Tag ON ItemTag.TagID = Tag.TagID
 WHERE Tag.Title = :title

2-Tabella:

SELECT Item.*
  FROM Item
  JOIN Tag ON Item.ItemID = Tag.ItemID
 WHERE Tag.Title = :title

Ma ci sono anche alcuni inconvenienti: potrebbe richiedere più spazio nel database (che potrebbe portare a più operazioni del disco che è più lento) e non è normalizzato che potrebbe portare a incongruenze.

L'argomento size non è così forte perché la natura stessa dei tag è che sono normalmente piuttosto piccoli, quindi l'aumento delle dimensioni non è grande. Si potrebbe sostenere che la query per il titolo del tag è molto più veloce in una piccola tabella che contiene ogni tag una sola volta e questo è certamente vero. Ma considerare i risparmi per non dover aderire e il fatto che è possibile costruire un buon indice su di essi potrebbe facilmente compensare questo. Questo ovviamente dipende fortemente dalle dimensioni del database che si sta utilizzando.

Anche l'argomento dell'incoerenza è un po 'controverso. I tag sono campi di testo gratuiti e non è prevista alcuna operazione come "rinomina tutti i tag" pippo "in" barra "".

Quindi tldr: sceglierei la soluzione a due tavoli. (In effetti lo farò. Ho trovato questo articolo per vedere se ci sono argomenti validi contro di esso.)

Se stai usando un database che supporta la riduzione della mappa, come couchdb, archiviare i tag in un campo di testo normale o in un campo elenco è davvero il modo migliore. Esempio:

tagcloud: {
  map: function(doc){ 
    for(tag in doc.tags){ 
      emit(doc.tags[tag],1) 
    }
  }
  reduce: function(keys,values){
    return values.length
  }
}

L'esecuzione con group = true raggrupperà i risultati in base al nome del tag e restituirà anche un conteggio del numero di volte in cui il tag è stato rilevato. È molto simile al conteggio delle occorrenze di una parola nel testo .

Utilizzare una singola colonna di testo formattata [1] per memorizzare i tag e utilizzare un motore di ricerca full-text capace per indicizzarlo. Altrimenti si verificheranno problemi di ridimensionamento quando si tenta di implementare query booleane.

Se sono necessari dettagli sui tag disponibili, è possibile tenerne traccia in una tabella gestita in modo incrementale oppure eseguire un processo batch per estrarre le informazioni.

[1] Alcuni RDBMS forniscono persino un tipo di array nativo che potrebbe essere ancora più adatto per l'archiviazione non necessitando di una fase di analisi, ma potrebbe causare problemi con la ricerca full-text.

Ho sempre tenuto i tag in una tabella separata e poi ho avuto una tabella di mapping. Ovviamente non ho mai fatto nulla su larga scala.

Avere una tabella "tag" e una tabella della mappa rende abbastanza banale generare nuvole di tag e simili poiché puoi facilmente mettere insieme SQL per ottenere un elenco di tag con conteggi della frequenza con cui ogni tag viene utilizzato.

Vorrei suggerire il seguente design: Tabella degli articoli: Itemid, taglist1, taglist2
questo sarà veloce e faciliterà il salvataggio e il recupero dei dati a livello di articolo.

In parallelo, costruisci un'altra tabella: i tag tag non rendono l'identificatore univoco dei tag e se esaurisci lo spazio nella seconda colonna che contiene, diciamo, 100 elementi creano un'altra riga.

Ora, durante la ricerca di articoli per un tag, sarà super veloce.