Quando si accede / manipola dati complessi, è meglio memorizzarlo in molti piccoli pezzi o in un grosso pezzo?

Il numero di operazioni sarà lo stesso in entrambi i casi. Fai una query per ottenere tutti gli accordi per una canzone, quindi fai un aggiornamento ogni volta che viene apportata una modifica. La differenza è davvero nella dimensione degli aggiornamenti. Con il metodo block, devi salvare la intera canzone ogni volta che cambi un accordo. Con il metodo individuale, i tuoi aggiornamenti saranno più piccoli e probabilmente più efficienti in generale, anche se la differenza potrebbe essere trascurabile.

Un'altra cosa da considerare è che il metodo nota per nota è più normalizzato, il che significa che avrai più opzioni di query aperte lungo la strada se la utilizzerai. Ad esempio, i principianti potrebbero filtrare accordi che non conoscono durante la ricerca di una canzone da apprendere, oppure puoi consentire la ricerca basata sugli accordi di apertura se qualcuno non conosce il titolo di una canzone. Anche se non pianifichi ora quelle funzioni, sarà un enorme problema cambiare il tuo database se vuoi qualcosa del genere in seguito.

In generale, una maggiore normalizzazione va bene per diversi motivi:

1. Meno duplicazioni di dati, con conseguente riduzione delle dimensioni del database fisico.
2. Migliore integrità dei dati: puoi utilizzare le chiavi esterne per far rispettare determinati requisiti.
3. Codice di aggiornamento più semplice, che hai identificato.
4. Ulteriori percorsi di accesso indicizzabili a sottoinsiemi di dati.

Svantaggi ( descritto bene qui ) include:

1. La normalizzazione consente di risparmiare spazio, ma lo spazio è economico.
2. La normalizzazione semplifica gli aggiornamenti, ma le letture sono più comuni.
3. Le prestazioni sono generalmente migliori con schemi meno normalizzati.

Suggerirei di iniziare con un progetto più normalizzato e prendere in considerazione la denormalizzazione solo in caso di problemi di prestazioni.

Fai in modo che la tua memoria sia più facile da gestire e abbastanza difficile da rovinare. Vai con uno schema ragionevolmente normalizzato. Vai con uno schema che non preclude usi diversi da quelli necessari nella prima versione, se possibile.

Se hai bisogno di tutto per mostrare le schede di una particolare canzone, puoi memorizzare un sacco di 6 tuple in un DB orientato al documento (come MongoDB), recuperandole come un unico documento.

In un RDBMS, lo memorizzerei allo stesso modo, in una tabella come questa:

table tab_column (
  song_id integer not null foreign key references song(id),
  ordinal integer not null, -- position in the tabulature
  s1 number(2), -- position on 1st string
  ...
  s6 number(2),
  primary key(song_id, ordinal)
)

Gli RDBMS sono validi per query semplici come quella necessaria per mostrare un brano:

select * from tab_column
where song_id = :song_id
order by ordinal;

Usando limit e offset , puoi mostrare parti di un brano.

In seguito sarà facile collegare tab_column a una tabella che elenca gli accordi con nome, se puoi riconoscere un accordo.

Questo è probabilmente lo schema più semplice possibile; Vorrei iniziare con esso.