Memorizzazione di più valori selezionati nel DB

1

Nella mia app per Android, c'è una domanda come "Quale dei seguenti alimenti hai mangiato oggi?" ( non la domanda effettiva ), con un elenco fisso di alimenti (ad esempio "Mele, banane, pizza, hamburger") da cui l'utente può selezionare tutto ciò che si applica.

Ora voglio memorizzare nel DB, quali risposte sono state selezionate in quale giorno. A mio avviso, ho diverse possibilità:

  1. memorizzali insieme in un campo come testo delimitato. Questo si interrompe se l'utente cambia le impostazioni della lingua, quindi non è davvero un'opzione per la mia app.
  2. Utilizzare una maschera di bit per convertire la selezione in un numero intero e memorizzarla nel database. Mantiene lo schema DB semplice e intuitivo e sfrutta l'abilità nativa di Android per selezionare la stringa corretta in base alla lingua impostata, ma rende praticamente impossibile eseguire una query per una risposta specifica. Le query SQL sono semplici, ma è necessaria un'ulteriore modifica dei dati nell'app.
  3. Fai una corretta normalizzazione. Bloats del database, poiché ci deve essere una tabella di risposte per ogni lingua supportata, ma sono possibili query per risposte specifiche. Le query SQL sono più complesse ma riducono la necessità di manipolazione dei dati nell'app stessa.

Quale di questi dovrei usare?
C'è una soluzione che non ho pensato è probabilmente meglio?
C'è una sorta di best practice o linee guida per questo tipo di problema nello sviluppo di Android?

    
posta snejjj 07.11.2015 - 20:04
fonte

1 risposta

1

Opzione 3 di un miglio di campagna, una volta che hai preso in considerazione l'ipotesi di gonfiare il design del database ...

Sembra che l'implementazione "ingigantirebbe" il database creando tabelle per lingua o campi aggiuntivi per lingua. Questa è una "bandiera rossa" da tenere in considerazione per il futuro: quando si aggiunge il supporto per un'altra lingua è necessario creare una tabella e dover aggiornare le query ecc. Quindi il progetto sta memorizzando DATA (la lingua / destinazione della traduzione) nel database DESIGN (la struttura della tabella) quando i due chiaramente non devono essere mischiati.

Una volta individuato l'errore, la soluzione è piuttosto semplice e potrebbe contenere due tabelle:

  • Foods (LanguageId, FoodId, Name) dove solo una combinazione di LanguageId e FoodId è unica.
  • Selections (UserId, FoodId, Timestamp) per registrare chi ha scelto cosa e quando.

Ecco fatto, hai finito con il minimo sforzo. L'elaborazione è semplice poiché FoodId è per cibo piuttosto che per traduzione e se l'utente cambia lingua, nulla è specifico per la lingua.

A seconda della progettazione della tua applicazione potresti fare un ulteriore passo in avanti piegando la tabella Foods in un contesto L18N più largo ... Qualcosa che valga la pena esplorare in un'applicazione multilingue. Ma ovviamente ciò dipende dalla tua vera applicazione.

    
risposta data 07.11.2015 - 22:16
fonte

Leggi altre domande sui tag