[ MPesic @ 25.03.2011. 00:23 ] @
Imam recimo tabelu

Code:
CREATE TABLE tabela (
ID INTEGER,
Ime VARCHAR(50),
Prezime VARCHAR(50),
PRIMARY KEY (ID)
);

Sta treba da uradim da bih prilikom INSERT upita MySQL kreirao nasumicni unikatni broj od recimo sedam cifara. Proveo sam sate i sate googlajuci za konkretan primer toga, ali nisam uspeo da nadjem nista sem teorijski kako bi trebalo to uraditi. Nasao sam ideje gde se pominje kreiranje korisnicki definisane funkcije za tu tabelu ili recimo da ID bude u timestamp formatu.
E sad je jedini problem sto ja ne znam kako sve to sprovesti u delo, bez konkretnog primera ne uspevam nikako razumeti to.
[ bogdan.kecman @ 25.03.2011. 00:32 ] @
jedini nacin da ti mysql generise unique id je auto increment .. dakle

Code:

CREATE TABLE tabela (
ID  int auto_increment not null primary key,
Ime VARCHAR(50),
Prezime VARCHAR(50),
);


i onda uradis ili
Code:

insert into tabela  (ime, prezime)  values ('pera', 'peric');


ili

Code:

insert into tabela  values (null, 'pera', 'peric');


i on ce svaki put za ID da stavi unique auto increment broj
[ MPesic @ 25.03.2011. 00:44 ] @
Znam za to ali ono sto zelim je mnogo kompleksnije. Hocu ID da mi bude 5448415 pa zatim recimo 3267187 itd id. auto_increment i auto_increment=neki broj ne zadovoljavaju kriterijum
[ bogdan.kecman @ 25.03.2011. 00:52 ] @
kao sto rekoh, jedini unique broj koji mysql generise je auto_increment a cak ni on ne radi kao "unique" - dakle ako ti rucno uneses neki broj u tabelu mozes da pokarambasis auto_inc posto mysql ne proverava da li on vec postoji ...

to moras da odradis sa strane software-a
[ ventura @ 25.03.2011. 07:47 ] @
Da li MySQL ima GUID?
[ Shinhan @ 25.03.2011. 08:25 ] @
Možda preko UDF, ali snimanje UUID u MySQL tabelu (kao primarni ključ) će loše da se odrazi na performanse, uvek je mnogo bolje koristiti čisto numeričke ključeve.

Da sam na tvom mestu ja bi dobro razmislio da li ti stvarno treba takav random ID. Zašto ti ne radi da je ID inkrementalan?
[ VladaSu @ 25.03.2011. 14:35 ] @
Nisam probao sa MySQL ali na drugim bazama mi je radilo tako sto napravis triger BEFORE INSERT, ako ti je ID null onda selektujes sve postojece ID-e iz tabele, imas ukupan broj redova,
minimalni moguci ID i maksimalni moguci ID i krenes nekom logikom da trazis slobodan broj i zamenis ID sa tim slobodnim brojem i pustis da se izvrsi INSERT. Npr. Firebird nije autoincrement
nego si ti sam pravio triger gde kazes da je id=MAX(id) + 1; (ranije a sada ne znam da li je tako)
Jeste malo sporiji insert ali necu da ulazim u to da li ti je stvarno potrebno tako nesto ...
[ bogdan.kecman @ 25.03.2011. 15:30 ] @
mysql ne ume da radi sa UUID/GUID ... a ako bi ga tukao kao PK morao bi to da radis kao CHAR (mysql ne ume da prepozna UUID kao visebajtni integer i da ga tako cuva). Od FOSS baza ja mislim da samo pgsql ima tu mogucnost.

e sad, ako ti treba unique id nezavistan od auto_inc .. ostavis auto_inc i dodas jednu kolonu koja je npr SHA(id) i eto ti ga veliki id koji je kanda unique
[ igor.vitorac @ 28.03.2011. 09:13 ] @
Citat:
bogdan.kecman: mysql ne ume da radi sa UUID/GUID ... a ako bi ga tukao kao PK morao bi to da radis kao CHAR (mysql ne ume da prepozna UUID kao visebajtni integer i da ga tako cuva). Od FOSS baza ja mislim da samo pgsql ima tu mogucnost.

e sad, ako ti treba unique id nezavistan od auto_inc .. ostavis auto_inc i dodas jednu kolonu koja je npr SHA(id) i eto ti ga veliki id koji je kanda unique


Bas si me bacio u razmisljanje sa ovim, jer imam dosta projekata (sto SugarCRM based, sto custom made) koje se oslanjaju delimicno na gore pomenuto...

Elem, za unique ID kod custom systema smo koristili UUID() prilikom insert-a, i to je radilo posao. A definisano kao:
`id` char(36) NOT NULL
PRIMARY KEY (`id`)

Sto se tice auto_increment polja (koji nije PK), imali smo nekad potrebu za time i to smo realizovali kao auto_increment i stavili da je UNIQUE i to radi posao:
`name` int(11) NOT NULL auto_increment,
UNIQUE KEY `name` (`name`)

Ne znam da li ima nekih problema u pomenutom pristupu?

[ bogdan.kecman @ 28.03.2011. 11:48 ] @
jedini problem je sto je UUID char() .. sto ce reci - uzima puno mesta na disku (nebitno) i uzima puno mesta u RAM-u (bitno) .. dodatno PK kao string je nesto sporiji za pretragu od PK-a koji je numeric (sama razlika u char vs numeric nije velika ali razlika u 16 bajtova koliko je bese uuid i 36 bajtova kolika je reprezentacija uuid-a kao stringa je povelika).

e sad .. uuid je mnogo koristan za neke stvari (posebno kada je stvarno unique za svaku masinu - mada sam imao prilike par puta da ne bude!!!) te ta blaga razlika u brzini moze da se otpise zbog te korisnosti .. e sada, sa porastom broja slogova u tabeli to sve vise i vise ima znacaj ... dakle nema "generalizovanog" odgovora .. ali dovoljno ti je da mysql kao rdbms nema pojma sta je uuid (nema taj tip, nema funkciju ..) ali ga mysql kao firma/tim/projekat koristi na dosta mesta (svaka varijabla koju prati enterprise monitor na primer je keyovana sa uuid-om na primer i isti se u mysql-u cuva u char(36) a ta baza ima milione rekorda u svakoj tabeli .. )
[ bogdan.kecman @ 28.03.2011. 12:17 ] @
btw, ja sam licno ovo uvek resavao sa 2 polja .. bilo mi je brze i iskusnije ... posto je ceo cim uuid-a da ce na 5 servera svaki put kada napravis novi on izgenerisati "unique" vrednost - dakle nece na 2 servera biti isti ... (sto je sve teoretski super ali se u praksi pokazalo da nije uvek tako) - mozes da radis scale out svoje aplikacije posto si siguran da je svaki ID unique.... e sad .. ja sam to resavao tako sto sam imao kompozitni kljuc od 1byte + int gde je byte "id servera" (hardkodiran u config fajlu) a int obican auto_increment .. sitna je razlika za insert ali je kasnije za rad cak jednostavnije