Ogni volta che le informazioni sono uno a uno (ogni utente ha un nome e una password), quindi è probabilmente meglio avere una tabella, poiché riduce il numero di join che il database dovrà eseguire per recuperare i risultati. Penso che alcuni database abbiano un limite al numero di colonne per tabella, ma non me ne preoccuperei in casi normali e puoi sempre dividerlo in un secondo momento, se necessario.
Se i dati sono uno a molti (ogni utente ha migliaia di righe di informazioni sull'utilizzo), allora dovrebbero essere suddivisi in tabelle separate per ridurre i dati duplicati (i dati duplicati sprecano spazio di archiviazione, spazio nella cache e rendono il database più difficile da mantenere ).
Potresti trovare l'articolo di Wikipedia su normalizzazione del database interessante, poiché ne discute in modo approfondito le ragioni:
La normalizzazione del database è il processo di organizzazione dei campi e delle tabelle di un database relazionale per ridurre al minimo la ridondanza e la dipendenza. La normalizzazione di solito comporta la divisione di tabelle di grandi dimensioni in tabelle più piccole (e meno ridondanti) e la definizione delle relazioni tra di esse. L'obiettivo è isolare i dati in modo che le aggiunte, le eliminazioni e le modifiche di un campo possano essere apportate in una sola tabella e quindi propagate al resto del database tramite le relazioni definite.
Denormalizzazione è anche qualcosa di cui essere consapevoli, perché ci sono casi in cui è meglio ripetere i dati (poiché riduce la quantità di lavoro che il database deve svolgere durante la lettura dei dati). Ti consiglio vivamente di normalizzare i tuoi dati il più possibile per iniziare e di denormalizzarli solo se sei a conoscenza di problemi di prestazioni in query specifiche.
