Progettazione di un database per il sistema di revisione

Question

Progettazione di un database per il sistema di revisione

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

1

Sto lavorando su un sistema di revisione e ho dei dubbi su come gestire la memorizzazione dei dati nel database.

Per questo sistema di revisione, ci sono tre diverse valutazioni che gli utenti possono inserire, li chiamerò ratingOne, ratingTwo e ratingThree. La mia soluzione attuale consiste nel chiamare tre diverse colonne nel database, rispettivamente one_rating , two_rating e three_rating (dove uno, due e tre sono informazioni commerciali che preferisco non rivelare)

C'è un modo migliore per archiviare questi dati? Ad esempio, nella richiesta API, questo viene gestito come un sub-oggetto in JSON i.e. all'interno del POST json c'è un secondo oggetto che è il seguente

[...],
"ratings": {
    "one": 1,
    "two": 2,
    "three": 3,
},
[...]

database-design

posta Pietro Bongiovanni 06.09.2017 - 10:00

fonte

2 risposte

Leggi altre domande sui tag database-design

Una tabella per ogni tipo di campo o un modello di tabella all-in-one? Macchina a stati con record di database

score 2 · Answer 1

Creerei due tabelle aggiuntive, ratings e rating_types .

La tabella rating_types ha un campo name e id . Avrebbe solo pochi record:

id | name
1  | Secret Rating 1
2  | Secret Rating 2
3  | Secret Rating 3
4  | Overall awesomeness

La tabella ratings legherebbe semplicemente le cose insieme, avendo chiavi esterne a rating_types e reviews :

id | review_id | type_id | rating
1  | 1         | 1       | 4
2  | 1         | 2       | 5
3  | 1         | 3       | 3
4  | 1         | 4       | 4
1  | 2         | 1       | 3
2  | 2         | 2       | 4
3  | 2         | 3       | 3
4  | 2         | 4       | 2

Questo rende più facile aggiungere "cose" extra su cui puoi valutare. Rende anche i calcoli più facili.

Per ulteriori dettagli, puoi consultare la normalizzazione del database

Se devi essere in grado di gestire diversi "tipi di classificazione" in diversi modi nel tuo codice, potresti espandere rating_types con un campo code che potrebbe avere un valore da verificare.

Solo una nota a margine, ma vorrei anche ristrutturare l'API JSON in questo modo:

{
...
    "ratings": [
        {"type": "1", "label": "Secret Rating 1", rating: 4},
        {"type": "2", "label": "Secret Rating 2", rating: 4},
        {"type": "3", "label": "Secret Rating 3", rating: 4},
        {"type": "4", "label": "Secret Rating Overall Awesomeness", rating: 4}
    ]
...
}

score 0 · Answer 2

Per un sistema di revisione, non solo è necessario archiviare le recensioni, ma anche eseguire query complessive su di esse.

Gli schemi di query potrebbero includere

Valutazione media
Numero di voti
Risultati ordinati per una valutazione particolare
Altre query di analisi che potresti desiderare

Dovrai bilanciare tra tre parametri

query di analisi
visualizzazioni coerenti (se i clienti vedono le modifiche di revisione immediatamente quando valutano)
Scala in base alla quale le recensioni vengono aggiornate o aggiunte.

Nel caso in cui il tuo requisito sia solo quello di archiviare le recensioni al momento, puoi utilizzare l'approccio di un negozio di documenti (le recensioni dei negozi in formato json).

D'altra parte potrebbe essere necessario eseguire query complessive nel qual caso un approccio a 3 colonne ha senso.

Un altro fattore da considerare sarà la velocità API (quante recensioni vengono aggiunte o aggiornate al secondo). Nel caso in cui questo numero sia molto alto (si pensi a siti come imdb / amazon), è necessario adottare un approccio documentale, dal momento che 3 indici su un tavolo possono ridurre gli aggiornamenti e la frequenza degli inserimenti. Dopo averlo archiviato in un archivio documenti è possibile avere visualizzazioni personalizzate (viste aggregate come valutazione media, ecc.) Per l'interfaccia utente calcolata in un processo asincrono. Infine, i dati possono essere pompati in un negozio di analisi come HBase o Redshift per le query di business