Come progettare un database che memorizza oggetti JSON di grandi dimensioni

0

Mi sto chiedendo quale sia l'approccio migliore per la progettazione di un database per la memorizzazione dei dati json cruciverba. Poiché il sito web è al momento, la vista front-end deve solo essere passata all'intero oggetto per rendere il cruciverba:

{
    grid: [15][15], // 2D array of letters
    clues: {
        across: { 
            clue_id: "here's an across clue" 
            ... 
        }, // Arbitrary number of clues
        down: {
            clue_id: "here's a down clue" 
            ... 
        } // Arbitrary number of clues
    }
}

Quali sono le opzioni più sensate quando si progetta il database?

Il mio istinto è di usare MySQL o Postgres e di archiviare i dati JSON in una singola colonna:

crossword _id | crossword_data

In futuro gli utenti potrebbero essere in grado di indizi "preferiti". In questo caso è meglio fare pratica per separare tutta la griglia e gli indizi da tabelle diverse?

Crosswords Table [has many clues]
-----------------------------------
| crossword_id   | crossword_grid |
-----------------------------------


Clues Table [has one crossword]
----------------------------------------------------------
| clue_id   | clue_direction | clue_text  | crossword_id |
----------------------------------------------------------

O sarebbe meglio memorizzare i dati cruciverba in un database NoSql separato?

Qualsiasi direzione in merito sarebbe molto apprezzata.

    
posta RobotEyes 14.11.2017 - 18:12
fonte

2 risposte

1

Quello che stai facendo è un approccio abbastanza buono. Ho fatto qualcosa di simile con doxdb che è un ID mappato su un blob. Il mio blob è un BSON, una rappresentazione binaria di JSON per l'ottimizzazione, quindi ha tabelle separate che vengono create sugli aggiornamenti del record.

In un certo senso questo è il modo in cui Apple Mail lo fa, tranne che per i BLOB che hanno usato i file dei messaggi e hanno costruito il database su di esso.

Un database di documenti nosql come elasticsearch e mongo può essere utilizzato come archivio dati e avere un MySQL per fornire le tabelle che è possibile utilizzare per eseguire query.

    
risposta data 15.11.2017 - 00:20
fonte
0

Penso che la decisione tra NoSql o DB relazionale non sia molto importante qui, ma se vai sulla rotta del DB relazionale, ecco alcuni suggerimenti.

Se il tuo caso d'uso implica che l'utente possa creare i propri cruciverba usando parole e indizi predefiniti, modellerei in questo modo:

Crossword Table [one crossword per row]
------------------------------------------------
| crossword_id   | clue_text  | crossword_text |
------------------------------------------------

Non vedo un valido motivo per normalizzarlo ulteriormente in un modo in cui è possibile avere più di un indizio per ogni cruciverba. Le parole e i loro indizi possono probabilmente essere gestite come un'unità atomica e modificate sempre insieme come una pausa.

Il loro posizionamento o direzione è importante solo nel contesto di una griglia:

Grid [one row per crossword grid]
------------------------------
| grid_id  | size_x | size_y | ... (maybe a column to distinguish different grids)
------------------------------

e

Placement Table [holds crosswords as well as their positions in the grid]
--------------------------------------------------------
| crossword_id  | grid_id | pos_x  | pos_y | direction |
--------------------------------------------------------

Qui, direction può essere un numero intero o un campo carattere per rappresentare i due valori across e down .

Se pensi di averne bisogno, puoi aggiungere una colonna letters alla tabella Grid , ma sarà ridondante rispetto ai dati già modellati.

    
risposta data 15.11.2017 - 18:05
fonte

Leggi altre domande sui tag