Implementazione di tag nell'oggetto

Question

Implementazione di tag nell'oggetto

#1 da (2 voti)

2

Nella mia app, sto implementando un sistema di questionari e vorrei implementare tag per domande - molto simili ai tag nelle domande qui o Stack Overflow.

Volevo avere alcuni consigli su come implementarlo come una proprietà nel mio oggetto. Dovrebbero essere una serie di stringhe - come sotto?

{
  "id": 123,
  "question": "What is your favorite color?",
  "tags": [
     "personality trait",
     "likes and dislikes"
  ]
}

O è meglio usare qualche tipo di identificatore, invece della verbosità effettiva?

{
   "id": 123,
   "question": "What is your favorite color?",
   "tags": [1234, 89645]
}

Sto pensando di archiviare queste domande in un database NoSQL e voglio che gli utenti siano in grado di eseguire query basate su questi tag. Ad esempio, se qualcuno vuole richiamare tutte le domande relative ai "tratti di personalità", dovrei essere in grado di eseguire una query che contiene quel particolare tag.

data-structures nosql database-design mongodb document-databases

posta Sam 30.11.2017 - 03:07

fonte

1 risposta

Leggi altre domande sui tag data-structures nosql database-design mongodb document-databases

Diagramma di sequenza per la classe astratta e derivata Risoluzione di chiavi esterne: cicli di interruzione per abilitare un ordinamento topologico

score 2 · Answer 1

Risposta breve

Dipende da cosa intendi fare con i tag dal punto di vista dell'applicazione. Se è solo per la ricerca in una sola lingua utente, e se la precisione del tag non è critica, basta andare per la stringa. Ma in tutti gli altri casi, l'id sarebbe un candidato migliore IMHO.

Risposta dettagliata

Nell'opzione 1 (stringa) consideri il tag come un semplice valore stringa (noto anche come oggetto valore) incorporato nel documento. Ciò ha le seguenti conseguenze:

Il punto buono è che tutti i valori necessari corrispondenti a un oggetto si ottengono in una singola query e che i tag saranno molto facili da usare nelle query.
Il tagging multilingue (vale a dire che ogni utente utilizza tag nella propria lingua) sarebbe purtroppo molto più costoso: il tag è solo una stringa e non esiste una semantica che la colleghi ad altre stringhe in altre lingue. Quindi, dimentica questa opzione se l'internazionalizzazione potrebbe essere nel campo di applicazione.
Una collezione di tag può essere successivamente creata per arricchire i tag con informazioni aggiuntive, come ad esempio un titolo breve, una descrizione e sinonimi di tag (come su StackExchange). Ma sarebbe più costoso da usare, perché richiederebbe query per un documento di tag che cerca per stringa. Un indice stringa può aumentare l'efficienza della ricerca, ma non il punto di accesso tramite un ID.
Le stringhe richiedono in generale più spazio. Se disponi di milioni di tag, ci sarà abbastanza spazio per i dati ridondanti.
Richiederebbe più sforzi per mostrare all'utente un elenco esauriente di tag (ad esempio per il completamento automatico). Quindi le informazioni sui tag rischiano di essere meno affidabili.

Nell'opzione 2 (id) consideri il tag come un entità (nel senso DDD) utilizzando normalizzato di MongoDB modello di dati anziché il suo modello incorporato . Le conseguenze sono:

L'inconveniente principale è che le applicazioni devono utilizzare query aggiuntive per risolvere il riferimento e ottenere il tag nome. Ma se hai bisogno di tag multilingue o se la tua applicazione ha comunque bisogno di accedere ad altre informazioni relative ai tag, questo non sarà un vero e proprio sovraccarico.
Il vantaggio principale è che avrai già documenti tag, per arricchire i tag man mano che le esigenze crescono.
L'accesso a un documento di tag usando un riferimento è molto veloce (più veloce che passare attraverso un indice indiretto).
Le informazioni di codifica sono compatte (un riferimento al documento è attualmente di circa 12 byte).
Il modello normalizzato evita le conseguenze sulle prestazioni degli array mutabili e in crescita, se il tagging viene aggiornato frequentemente.
Si utilizza un meccanismo progettato per gestire one a molte relazioni tra entità indipendenti.
Puoi sviluppare ricerche complesse usando le relazioni tra tag (e.g.synonyms, inclusione).

Consigli

Personalmente, mentre lavoro in un ambiente internazionale, opterei immediatamente per l'opzione 2. Il problema è che se inizi con l'opzione 1, sarà difficile evolvere in seguito. Per esempio, sospetto che qualcuno su LinkedIn abbia usato tag di stringa nel modello db quando il tagging delle abilità è stato inizialmente lanciato, quindi diversi anni dopo, sebbene sia possibile visualizzare il proprio profilo in più lingue, i tag delle abilità non sono tradotti quindi utilizzabili solo in inglese o mescolando lingue diverse.