Che è più veloce: molte righe o molte colonne?

Question

In MySQL, è generalmente più veloce / più efficiente / scalabile restituire 100 righe con 3 colonne o 1 riga con 100 colonne?

In altre parole, quando si memorizzano molti key = > coppie di valori relative a un record, è meglio memorizzare ogni chiave = > coppia di valori in una riga separata con record_id come chiave o avere una riga per record_id con una colonna per ogni chiave?

Inoltre, supponiamo anche che le chiavi debbano essere aggiunte / rimosse abbastanza regolarmente, il che presumo influenzerebbe la manutenibilità a lungo termine dell'approccio a più colonne una volta che la tabella sarà sufficientemente grande.

Modifica: per chiarire, mediante "una base regolare". Intendo l'aggiunta o la rimozione di una chiave una volta al mese circa.

Answer 1

Non devi mai aggiungere o rimuovere colonne su base regolare.

Answer 2

http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

Ci sono molte cose cattive su questo modello e non lo userei se ci fosse un'altra alternativa. Se non conosci la maggior parte (tranne alcuni campi personalizzabili dall'utente) delle colonne di dati necessarie per la tua applicazione, devi dedicare più tempo alla progettazione e scoprirlo.

Answer 3

Se le tue chiavi sono preimpostate (conosciute in fase di progettazione), allora sì, dovresti mettere ciascuna chiave in una colonna separata.

Se non sono noti in fase di progettazione, è necessario restituire i dati come un elenco di coppie chiave-valore che è necessario analizzare successivamente al di fuori del RDBMS .

Answer 4

Se stai memorizzando coppie chiave / valore, dovresti avere una tabella con due colonne, una per la chiave (rendila PK per la tabella) e una per il valore (probabilmente non è necessario indicizzarla) . Ricorda, " La chiave, l'intera chiave e nient'altro che la chiave. & Quot;

Nell'approccio a più colonne, scoprirai che la tua tabella cresce senza limiti perché la rimozione della colonna comporta il nuke di tutti i valori e non vorrai farlo. Parlo per esperienza qui avendo lavorato su un sistema legacy che aveva una tabella con quasi 1000 colonne, la maggior parte delle quali erano bit field. Alla fine, smetti di essere in grado di fare il caso di eliminare una delle colonne perché qualcuno potrebbe lo sta usando e l'ultima volta che l'hai fatto, hai lavorato fino alle 2 del mattino per tornare ai backup.

Answer 5

Primo: determina la frequenza di accesso ai tuoi dati. Se i dati devono sempre essere recuperati in un colpo solo e la maggior parte di essi utilizzati, prendere in considerazione la memorizzazione di tutte le coppie di chiavi come valore serializzato o come valore XML. Se hai bisogno di fare qualsiasi tipo di analisi complessa su quei dati e hai bisogno delle coppie di valori, allora le colonne sono ok ma limitale ai valori che sai che dovrai eseguire le tue query. In genere è più semplice progettare query che utilizzano una colonna per un parametro rispetto alla riga. Troverai anche più facile lavorare con i valori restituiti se sono tutti in una riga rispetto a molti.

Secondo: separa i dati a cui accedi più frequentemente e inseriscili nella sua tabella e gli altri dati in un'altra. 100 colonne sono molte, quindi ti consiglio di dividere i tuoi dati in blocchi più piccoli che saranno più gestibili.

Infine: se si dispone di dati che possono cambiare frequentemente, è necessario utilizzare creare la colonna (chiave) in una tabella e quindi utilizzare il valore della chiave numerica rispetto al quale memorizzare il valore della chiave. Ciò presuppone che utilizzerai la stessa chiave più di una volta e che dovresti accelerare la tua ricerca quando vai a fare la tua ricerca.