Prima , a volte questo modello semplifica notevolmente l'interrogazione dei dati. Ho fatto una domanda un paio di giorni fa qui e alcuni utenti hanno suggerito perché non ho cambiato il mio modello in un modulo 1NF per semplificare l'interrogazione dei dati. Solo quando si sono resi conto che ero bloccato con questo progetto, hanno fornito alcune risposte alla domanda. Il punto è che ho avuto la fortuna di avere solo 12 colonne da riassumere; altrimenti, se la mia tabella conteneva 300 colonne, forse nessun utente si è preso la briga di scrivere una query per quel problema. :-)
Secondo , a volte l'implementazione di questo progetto è più facile a causa di alcune limitazioni imposte naturalmente dai database. Se il tuo meta_key i valori contengono alcuni valori lunghi più grandi di 30 caratteri, o devi abbreviare i valori ed eseguire la mappatura da qualche parte o questa potrebbe essere l'unica opzione che potresti avere.
Finalmente , le prestazioni sono molto importanti; è vero. Ma, d'altra parte, ci sono alcune tecniche che potresti applicare per migliorare le prestazioni; ad esempio creando indici appropriati, partizionamento di tabelle e così via.
In questo caso, le dimensioni del tavolo sono molto ridotte. Quindi, a meno che le tue query non siano molto complicate come avere calcoli pesanti e join e aggregazioni complicate, e se l'applicazione non è sensibile a piccole frazioni di tempo, suppongo che non soffriresti di prestazioni se adottassi questo modello.
Alla fine , se sei ancora troppo preoccupato per le prestazioni, ti suggerisco di creare entrambi i modelli, popolarli con alcuni dati casuali o reali e analizzare i costi del piano per vedere quale modello si adatta meglio alle tue esigenze.
