Tabelle, quanto costano in termini di performance e spazio?

[American]

Ho un enorme dilemma. In un database ho memorizzato i vari dati di login dell'utente (email + password), considerando che l'utente può a propria discrezione modificarli non so se conviene utilizzare la medemisa tabella per fare entrambe le cose o due tabelle distinte..

Mi spiego, sia che l'utente deve cambiare mail sia che deve resettare la password, nella tabella utenti_attesa_conferma memorizzo un un codice random per fare poi le opportune verifiche prima della modifica.
Quindi utenti_attesa_conferma è strutturato con questi tre campi: email, idUtente, codiceRandom

Il riutilizzare la stessa tabella sia per la modifica password che l'email mi permette di avere tutto più "concentrato" e di sprecare meno spazio nel DB, ma allo stesso tempo che accade se un utente prima chiede la modifica mail e poi il reset della password? La prima operazione verrebbe sovrascritta dalla seconda.. Insomma, ci sono pro e contro, quindi per valutare la soluzione da adottare mi servirebbe capire quando effettivamente costa in termini di performance e spazio creare un ulteriore tabella riservata unicamente al reset delle password

[las]

Bisognerebbe capire anche di quale DB stiamo parlando, comunque in linea di principio si può dire che la tabella di per se non occupa nessuno spazio o risorsa, il fatto che inizi o meno a occupare spazio e/o risorse dipende dalla sua struttura e sopratutto dal numero di record che contiene,

Nel caso che hai descritto, a prescindere dal discorso spazio/risorse, io terrei un unica tabella utenti dove metti email, password e codiceRandom questo perchè, salvo casi particolari, è preferibile evitare di avere due tabelle collegate 1:1 sopratutto come in questo caso dove in pratica la seconda tabella ti serve solo per un paio di campi.

[American]

spetta, la tabella utenti esiste a prescindere, poi c'è questa tabella collaterale (utenti_attesa_conferma) che creai appositamente per la fase di registrazione.
In pratica l'utente si registra e nel DB vengono memorizzati tutti i suoi dati nella tabella utenti, mentre nella tabella utenti_attesa_conferma vanno a finirci soltanto i dati relativi alla verifica mail.
Dici che ho sbagliato in partenza il progetto e avrei potuto fare tutto all'interno della stessa tabella al fine di evitare il collegamento 1:1? Mi consigli di ri-progettarlo?

[las]

Io sicuramente avrei messo tutto in un unica tabella, ovviamente se sei già avanti con il progetto devi valutare tu quanto ti costa la "variante in corso d'opera" in temini di riscrittura di codice, sincronizzazione tabelle etc..

[American]

Però ho pensato una cosa... così facendo rischierei di avere, nella tabella utenti, dei campi superflui e inutilizzati per ciascun record.
In pratica utenti diventerebbe così:
email - password - nome - cosgnome - emailUpdate - codiceRandom

emailUpdate e codiceRandom verrebbero utilizzati solo quando effettivamente l'utente chiede di modificare la mail, restando quindi vuoti per la maggior parte del tempo..

Mentre invece creando una tabella collaterale apposita per il servizio di update mail ridurrei lo spreco al minimo creando solo record e campi strettamente necessari (una volta convalidata la mail infatti il record viene del tutto eliminato).
Non so se mi sono spiegato.

Ma torniamo sempre al discorso "tecnico" su quante risorse vengonop sprecate con una soluzione piuttosato che con un'altra..

(cmq il database è MySql)

[las]

i campi varchar se vuoti occupano un solo byte, quindi non è una grossa dimensione, se consideri poi che facendo una nuova tabella dovrai in qualche modo collegarla a quella utenti quindi ti servirà un id, supponiamo un int sono già 4 byte, quindi ogni riga della nuova tabella 'pesa' quanto 5 righe rispetto ai campi aggiuntivi della tabella principale.

Poi potresti pensare anche a sistemi che non richiedono di registrare nulla, ad esempio una cosa di questo tipo:

l'utente inserisce nel form la nuova email: nuova@mail.it

il sistema genera il codice in questo formato:
md5("idUtentenuova@mail.itMIOCODICECHECONSOCOSOLOI O") = "ABCDEFGHI"

viene spedita una mail di conferma che riporta il seguente link:

valida.php?idUtente=5&email=nuova@mail.it&codice= ABCDEFGHI

su valida.php controlli che

md5($_GET['idUtente'].$_GET['email']."MIOCODICECHECONSOCOSOLOIO") = $_GET['codice'];

e se passa il controllo sostituisci la nuova email con la vecchia nel record con idUtente=$_GET['idUtente]

[American]

ottimo metodo quello suggerito, me lo riserverò per le prossime operazioni

Tornando invece alla memorizzazione temporanea del codice random nel DB, hai detto

i campi varchar se vuoti occupano un solo byte

ma intendi 1 byte per ciascun record o è l'intera colonna ad occupare così poco spazio? Perchè nel primo caso, considerando ad esempio l'ipotetica cifra di 1000 utenti, occuperei ben 1000 byte

Con il sistema della tabella collaterale invece, ipotizziamo che solo il 10% di quegli utenti ha una verifica mail in sospeso: 100*5 byte = 500byte
Il risparmio c'è

[optime]

non capisco perché ti stai preoccupando per 1k di spazio...

[las]

ottimo metodo quello suggerito, me lo riserverò per le prossime operazioni

Tornando invece alla memorizzazione temporanea del codice random nel DB, hai detto

ma intendi 1 byte per ciascun record o è l'intera colonna ad occupare così poco spazio? Perchè nel primo caso, considerando ad esempio l'ipotetica cifra di 1000 utenti, occuperei ben 1000 byte

Con il sistema della tabella collaterale invece, ipotizziamo che solo il 10% di quegli utenti ha una verifica mail in sospeso: 100*5 byte = 500byte
Il risparmio c'è

1 byte per ciascun record, quindi si, al 10% hai un risparmio, ma già al 20% sei in pari ... poi però devi valutare anche il carico maggiore del DB che dovrà interrogare 2 tabelle anzicè una .... ma come ha detto optime stiamo parlando di cifre abbastanza ridicole per i server di oggi, quindi alla fine qualsiasi scelta va bene ..... a meno che tu non abbia 10 milioni di utenti ovviamente.

[optime]

10 milioni di utenti a 1 byte extra l'uno sono comunque 10Mb... 2-3 foto! Peserebbe molto di più il carico delle join superflue che 10 mb