Progettazione di una ricerca efficiente per soluzione di tag

0

Ho un progetto in cui gli utenti saranno in grado di taggarsi con tag skills (magari predefiniti nel sistema), e quindi i project manager di un'azienda sarebbero in grado di cercare il meglio utente con una serie di competenze per un determinato compito. Ad esempio: Java sarebbe un tag, o forse Android , ecc. Userò un DB relazionale. Ho finora le seguenti opzioni:

  1. Utenti , UserTags , Tag .
  2. Utenti e Tag tabelle, memorizzando i tag di ciascun utente come una colonna di testo user_tags (in Utenti ).

N ° 1 è il modo più corretto per farlo in termini di pura progettazione logica, ma al momento della ricerca richiederebbe di interrogare le tre tabelle. Inoltre, il Project Manager può anche cercare per nome dell'utente, quindi forse una query potrebbe essere:

SELECT users.name, users.id FROM users, user_tags, tags WHERE (tags.name={query} AND tags.id=user_tags.tag_id AND user.id=user_tags.id) OR users.name LIKE '%{query}%' LIMIT N .

Non so se si tratta di una query efficiente, nota che ho un OR con una dichiarazione LIKE.

Con l'opzione N ° 2 avrò una penalità di archiviazione (memorizzando molte volte lo stesso nome TAG per ciascun utente), ma forse potrei eseguire una ricerca indicizzata FULLTEXT nella colonna i tag e nome di Utente , quindi la query su una sola tabella con un indice FULLTEXT. Qui la tabella Tag sarà utile come tabella di controllo, convalidando se i tag selezionati dall'utente sono consentiti.

Quindi, quale pensi che sia l'approccio migliore?

    
posta gabdev 02.06.2018 - 20:05
fonte

1 risposta

1

Penso che vorrai dire che anche un project manager che cerca "c #" ottiene ".net" ma non "c"

Ciò significa che dovrai raggruppare i tag in categorie, evitare che "C #" e "c #" siano tag diversi e che sia più intelligente con la tua ricerca rispetto a un semplice confronto tra parole.

Avrai bisogno di più tabelle collegate e vuoi fare riferimento a un tag tramite il suo id piuttosto che la sua rappresentazione inglese scritta. Quindi dovrei usare la tabella di join in questo caso.

(anche se ho la sensazione che un db relazionale potrebbe non essere l'approccio più scalabile a lungo termine)

    
risposta data 02.06.2018 - 20:41
fonte

Leggi altre domande sui tag