Organizzare tabella per le categorie in un database

[lore83]

Ciao a tutti.
Capita molto frequentemente di fare delle tabelle che raccolgono delle categorie da utilizzare come riferimenti per chiavi esterne in altre tabelle (ad esempio da una parte tabella PILOTI FORMULA 1 e dall'altra una tabella CASE AUTOMOBILISTICHE, quest'ultima la intendo come tab per le categorie). Tale tabella avrà almeno 2 colonne: id e nome_categoria.

Ora la mia domanda è: in questa tabella l'id è meglio che sia intero o alfanumerico? Questo problema sorge pensando ad un'eventuale rimozione di un record di tale tabella che creerebbe un 'disordine' logico, è ovvio che dal punto di vista sostanziale non cambia assolutamente nulla, chiamare l'id 'gino' o '34354' è la stessa cosa.

Che ne dite?

[bubi1]

è ovvio che dal punto di vista sostanziale non cambia assolutamente nulla, chiamare l'id 'gino' o '34354' è la stessa cosa.

sbagliato. 34354 ti ci sta in una colonna smallint unsigned o mediumint, che come ricerca/indicizzazione/ordinamento/collegamento relazionale sara molto-molto piu' veloce rispetto ad una colonna char o varchar per memorizzare 'gino'. Puoi pensarla anche cosi: una smallint occupa 2 bytes, mentre una char(4) ne occupa appunto 4.
Naturalmente se hai 10 righe nel tuo db, tutto questo e' irrilevante..

Non ho capito chi e dove crea il disordine logico.

[lore83]

ciao, grazie per la risposta.

Il disordine logico mi viene pensando a questo: se domani volessi cancellare dalle CASE_AUTOMOBILISTICHE (ipotizziamo esserne 10) la BrawnGp che ad esempio ha l'id numero 2, a quel punto l'id 2 verrebbe rimosso per sempre e la prossima casa che verrà aggiunta sarà comunque la 11, corretto? Sostanzialmente nn cambia nulla, è forma.

[Luke70]

Direi che gestire un id alfanumerico è molto più complesso oltre che occupare più risorse: il problema principale che vedo è che devi assicurarti di non avere duplicati nell'id. Questo è facile se è numerico definendolo autoincrementale mentre è complesso se alfanumerico.

La mancanza di un valore id non mi sembra un problema anche perchè di solito l'id non ha bisogno di essere reso noto all'utente.

[bubi1]

il problema principale che vedo è che devi assicurarti di non avere duplicati nell'id. Questo è facile se è numerico definendolo autoincrementale mentre è complesso se alfanumerico.

Questa argomentazione non e' del tutto vera; basterebbe impostare il campo come unique not null per non avere duplicati.

Il resto e' giusto, non e' assolutamente un problema se ci sono delle interruzioni di serialita' nella chiave primaria.

[Luke70]

veero, ma devi gestire l'eventuale errore che riceveresti mentre sa fai un autoincrementale fa tutto MySql

[bubi1]

Ah, in questo senso si Anche se ci sono casi quando si usa uuid() su un campo unique, senza problemi.
Ma nei casi normali, mi associo - autoincrement numerico batte l'alfanumerico sia con le prestazioni che con la comodita'