Come progettare un database in cui più tag (string) devono essere associati a un id?

Question

Come progettare un database in cui più tag (string) devono essere associati a un id?

#1 da (13 voti)
#2 da (0 voti)
#3 da (0 voti)

5

Devo progettare un database in cui devo associare un audio_id con più tag (parole). Sto prendendo in considerazione i seguenti approcci per selezionarne uno da:

1) Per avere più campi per più tag (colonne: tag1, tag2, tag3 .... tag10) corrispondenti a un singolo audio_id. Il numero di tag nella mia applicazione non sarà superiore a 10-15.

2) Per salvare i tag (parole) come una singola stringa separata da virgola corrispondente a un singolo audio_id.

3) Per salvare le associazioni (tag: audio_id) in una tabella separata. Ma il problema qui è che le associazioni possono essere n a n. È possibile associare più tag a un audio_id e lo stesso tag può trovarsi in più audio_id.

Per favore fatemi sapere se può esserci un progetto alternativo per questo scenario o è meglio prendere in considerazione qualsiasi altro tipo di database diverso da MySQL.

Il numero totale di tag sarà di circa un milione e audio_id di circa poche migliaia. Sono preoccupato per le prestazioni del sistema.

database database-design database-development

posta Venkatesh 04.11.2011 - 17:21

fonte

3 risposte

Leggi altre domande sui tag database database-design database-development

Valore di mantenimento degli output di debug Quanta documentazione dovrebbe aspettarsi un cliente da un team individuale? [chiuso]

score 13 · Answer 1

Suggerirei di avere una tabella per i tag, una tabella per "audio" e una terza tabella per tenere traccia del tag associato a quale audio. Qualcosa come:

tags_audios

audio_id   | tag_id
----------------------------
1          | 2
1          | 3
2          | 1
2          | 3
3          | 6

Questo di solito è il modo in cui vedo le relazioni m: n memorizzate ed è molto simile alla Soluzione n. 3 che hai proposto.

La soluzione numero 1 darà problemi quando decidi che fai vuoi più di 15 tag. Dovrai anche cercare tutte le colonne dei tag quando vuoi trovare un solo valore.

Non riesco a pensare a una buona situazione per utilizzare la Soluzione n. 2, tranne forse in un sistema di reporting in cui aggregare tutti i tag in una stringa renderà più facile generare il rapporto finale.

score 0 · Answer 2

Questo di solito è fatto con una relazione molti-a-molti.

Ciò implicherebbe le seguenti tabelle:

audio (id, tags, ...)
tag (id, name, ..?)
tag_audio (audio_id, tag_id)

Inoltre, come puoi vedere ho incluso un campo "tags" nella tabella audio. Questo sarebbe un valore memorizzato nella cache (virgola / punto e virgola / delimitato) per le volte in cui non è necessario il 100% di valori corretti. Potresti semplicemente usare questo campo, il che farebbe risparmiare su joins aggiuntivi nel database.

In secondo luogo, come best practice, i nomi delle tabelle dovrebbero essere sigilli. Puoi tuttavia regolare questo esempio come ritieni opportuno.

score 0 · Answer 3

Dipende veramente da come usi i tag . Se tutto ciò che stai facendo è salvarli e visualizzarli, allora un semplice campo separato da virgole potrebbe funzionare meglio. Se stai cercando, ordinando e filtrando i tag, una disposizione a 3 tavoli (come già descritto) potrebbe funzionare meglio.

Devi davvero capire quali saranno i modelli di utilizzo. Una volta ottenuto ciò, è possibile capire quale layout della tabella funziona meglio. (E naturalmente, devi bilanciare spazio su disco e prestazioni nella tua decisione.)

Potrebbe essere necessario eseguire alcuni test (con un numero LARGE di righe) prima di poter decidere con precisione quale modello utilizzare.