Newsgroup: it.comp.lang.delphi
Titolo: ID random

Ho un programma Delphi collegato a Firebird. Per aggiungere un record 
devo generare da programma un ID random (ma unico nella db).
Posso controllare se il numero gia` esiste e in caso negativo aggiungere 
il record alla db.
Come evitare il possibile conflitto che due istanze del programma 
generino lo stesso numero e una riesca ad aggiungere il record nel 
intervallo fra il controllo se ID esite e l'inserimento del record 
dell'altra istanza?
Ovvero due processi concorrenti che inseriscon record in una base dati 
con ID generati a caso. Come risolvere il problema dell'unicita` degli ID?
Grazie
Enrico

> Come risolvere il problema dell'unicita` degli ID?
Utilizzando un generatore.
Ma non ho capito perchè gli ID debbano essere casuali...
-- 
Ciao!
Marco Kregar
marco....@FirebirdSQL.it
www.FirebirdSQL.it
"over the bench the goat sings, under the bench the goat dies"

 
Proprio li` e` la differenza. Il generatore genera numeri sequenziali e 
io ho bisogno di numeri casuali.
Enrico

 io ho bisogno di numeri casuali.
In questo caso, non è preferibile adottare un generatore casuale "lato
client" (ad esempio, la GUID) da assegnare al record prima del suo invio
al database server?
-- 
Marco «Alka» Breveglieri
  ABLS Team S.n.c. - Software & Web
  Via De Gasperi, 14
  42019 Scandiano (Reggio Emilia)
 
http://www.abls.it

 
Metodo "riprova e sarai piu` fortunato". Semplicemente genero un ID 
casuale nel client e provo ad aggiungere il record con questo ID. Se ci 
riesce ok altrimenti genero nel client un nuovo ID e itero fino al successo.
Ho provato vari metodi e mi sembra il piu` semplice. Devo solo gestire 
l'errore di risposta di Firebird.
Grazie per l'aiuto
Enrico

E come li generi i numeri casuali?


 solo gestire l'errore di risposta di Firebird.  Grazie per l'aiuto
Più semplice di quello proposto da Marco Breveglieri non mi sembra. Se
generi un GUID e lo applichi nel DB non hai praticamente probabilità
che vada in collisione.
L'unico problema potrebbe essere se hai dei legacy db oppure se
definire un campo testo di 16 byte non è fattibile.
Antonio

 definire un campo testo di 16 byte non è fattibile.
Forse si potrebbe utilizzare una chiave primaria basata su due campi 
interi, entrambi generati casualmente.


Perchè dici 2 processi concorrenti se fossero solo 2
sarebbe sufficiente dire che :
Repeat
  ...
 Genero numero veramente casuale n (randomize sul client).
  ...
Until non esiste.
Allora Post con ID pari (2*n)
Nell'altro Client
Repeat
  ...
 Genero numero veramente casuale n (randomize sul client).
  ...
Until non esiste.
Allora Post con ID dispari (2*n)+1
Questo perchè se un client genera numeri casuali pari e l'altro genera
numeri casuali dispari dovresti essere a posto.
Se i client non sono due ma tre si cambia un pochino...
3*n
(3*n)+1
(3*n)+2
Se i client sono 4 :
 
4*n
(4*n)+1
(4*n)+2
(4*n)+3
Se i client sono m :
m*n
(m*n)+1
(m*n)+2
...
...
(m*n)+(m-1)
Ciao
Mario - (
mari...@inwind.it
)
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

di collisione (come indicava Antonio) sono molto molto basse.
Beh dai, le probabilità che due GUID siano uguali non sono molto molto
basse, di più (il GUID è un numero circa = 3.4 * 10^38) . Direi che è
più probabile che il cielo ci cada sulla testa :p
-- 
Ore 18.30: premo invio.

 più probabile che il cielo ci cada sulla testa :p
Hai ragione...è che mi sono dimenticato di mettere "molto molto" tra 
virgolette per esprimere questo concetto in modo ironico. :-D
