[DATABASE] Chiavi Primarie numeriche autoincrement o HASH?

[daniele_dll]

mmm

domandona come da titolo...conviene utilizzare degli hash come chiavi primarie o degli id autoincrement?

Ovviamente ci scono delle casistiche scontate (non a prezzo ribassato, ma situazioni ovvie) come ad es una tabella sessioni, è ovvio usare un hash, o in un elenco prodotti è ovvio usare un id numerico...ma ad esempio...in un elenco degli ordini eseguiti? o in un elenco di files presenti in una tabella?

mettiamo che l'utente X possa scaricare dei file ma per via di una falla del software possa scaricare tutti i file che vuole modificado l'id...se ci fosse una chiave primaria sarebbe molto facile...se ci fosse un hash al posto della chiave primaria sarebbe molto complicato...ci vorrebbe molta fortuna...

inoltre ormai i sistemi di hashing sono diventati fondamentali ovunque e mi domandavo se non servivano realmente anche come chiavi primarie, allagarndo però il loro campo di utilizzo?

---

ovviamente nasce una domanda spontanea...è possibile mettere come valore di default in una tabella del codice SQL da eseguire e non del normale testo???
ho provato a mettere come default nel campo primario della tabella

MD5(CONCAT(RAND(), CURTIME()))

ma mi ha inserito questo pari pari :\

sciauz

[piero.mac]

insert into prove1 (md5_a) values
(MD5(CONCAT(RAND(), CURTIME())))

mi rende:

md5_a
039d90f42d6777086a5869e09fd27894

Si potrebbe anche usare piu' campi per definire una chiave primaria, poi nella ricerca userai CONCAT vanificando le intrusioni e mantenendo pero' la possibilita' di ordinamento sul campo autoincrement. Es.:

ALTER TABLE `prove1` DROP PRIMARY KEY ,
ADD PRIMARY KEY (`id` , `md5_a`)

oppure un bel unix_timestamp al posto di MD5()

[daniele_dll]

si, se lo metti nella insert si, io avevo provato a metterlo nel DEFAULT di uno dei valori del create table

se vado ad usare un concat durante alla ricerca uccido del tutto mysql dato che questo non può essere praticamente ottimizzato :\

usare più campi è anch'esso una possibile soluzione ma non so se sarebbe possibile usare un autoincrement con la primary key settata su, questo però dovrei verificarlo

lo unix timestamp lo scarto per via del fatto che se faccio due inserimenti nello stesso secondo ho 2 doppioni e questo non deve succedere

[piero.mac]

[supersaibal]Originariamente inviato da daniele_dll
se vado ad usare un concat durante alla ricerca uccido del tutto mysql dato che questo non può essere praticamente ottimizzato :\

usare più campi è anch'esso una possibile soluzione ma non so se sarebbe possibile usare un autoincrement con la primary key settata su, questo però dovrei verificarlo

lo unix timestamp lo scarto per via del fatto che se faccio due inserimenti nello stesso secondo ho 2 doppioni e questo non deve succedere [/supersaibal]

Ne avevamo gia' discusso in un thread... e si era anche visto quali sono le caratteristiche ideali per una chiave primaria.

L'autoincrement e' a se stante e quindi funziona. La chiave primaria su due campi valuta l'unicita' della coppia e non della singola colonna, pero' a sua volta la colonna id autoincrement e' univoca, quindi siccome il primo campo e' l'id ci sara' un solo id con lo stesso numero indicizzato. La seconda colonna servira' solo come validazione dell'id passato. Ma e' assolutamente inutile ai fini della chiave primaria, essendo l'autoincrement univoco di per se e quindi da evitare se uno dei due campi e' tale.

Il timestamp non e' solo identico per lo stesso secondo di inserimento, ma per tutte le righe inserite con la stessa query, la data ora di sistema viene letta una volta sola.

Alla fine un campo che sia univoco, di lunghezza fissa, mai nullo o da modificare, semplice, senza significato per i dati del record lo ottieni solo con un campo numerico e autoincrement. oppure numerico con un valore generato random per evitare la continuita numerica, ma perderesti la possibilita' di ordinamento per valori a scalare e le funzioni di insert_id.

Un sistema? aggiungi 3 o 4 lettere random all'id quando circola nei form o dove potrebbe essere intercettato, e poi le rimuovi prima di passare il valore alla query.