Care este opinia dvs. cu privire la utilizarea UUID-urilor ca identificatori de rânduri de baze de date, în special în aplicațiile web?

Cred că aceasta este una dintre aceste probleme care provoacă dezbateri cvasi-religioase și aproape inutil să vorbim. Aș spune că folosiți ceea ce preferați. În 99% dintre sisteme nu va conteza ce tip de cheie folosiți, astfel încât beneficiile (menționate în celelalte posturi) de a folosi un fel peste celălalt nu vor fi niciodată o problemă.

Lucrez cu un sistem de management al studenților care utilizează UUID-urile sub forma unui număr întreg. Au o masă care dețin următorul ID unic.

Deși aceasta este probabil o idee bună din punct de vedere arhitectural, ea face ca munca zilnică să fie dificilă. Uneori este nevoie să faceți inserții în vrac și având un UUID face acest lucru foarte dificil, de obicei necesitând scrierea unui cursor în loc de o simplă instrucțiune SELECT INTO.

Nu cred că un GUID vă oferă multe beneficii. Utilizatorii urăsc adrese URL lungi și incomprehensibile.

Creați un ID mai scurt pe care îl puteți mapa la adresa URL sau puteți impune o convenție unică de nume de utilizator ( http: // exemplu. com / utilizator / brianly ). Băieții de la 37Signals vă vor bate joc de faptul că vă faceți griji despre ceva de genul asta atunci când vine vorba de o aplicație web.

De altfel, puteți forța baza de date să înceapă să creeze ID-uri întregi de la o valoare de bază.

Nu pot spune despre partea web a întrebării. Dar uuids sunt excelente pentru n-tier aplicații. Generarea PK poate fi descentralizată: fiecare client generează propriul PK fără risc de coliziune. Diferența de viteză este, în general, mică.

Asigurați-vă că baza de date acceptă un tip de date eficient de stocare (16 octeți, 128 biți). Cel puțin puteți codifica șirul uuid în baza64 și utilizați caracterul (22).

Le-am folosit pe larg cu Firebird și recomand.

Mai degrabă decât URL-uri ca aceasta:

http://example.com/user/783

De ce nu ai:

http://example.com/user/yukondude

Ceea ce este mai prietenos pentru oameni și nu scapă de acea mică informație?

Utilizăm GUID-urile ca chei primare pentru toate tabelele, deoarece se dublează ca RowGUID pentru replicarea MS SQL Server. O face foarte ușor atunci când clientul deschide brusc un birou într-o altă parte a lumii ...

Cred că folosirea unui GUID ar fi cea mai bună alegere în situația dvs. Este nevoie de mai mult spațiu, dar este mai sigur.

Pentru ceea ce merită, am văzut o procedură stocată de lungă durată (9+ secunde) la doar câteva sute de milisecunde de timp de execuție pur și simplu prin trecerea de la tastele principale GUID la întregi. Nu înseamnă că afișează un GUID este o idee proastă, dar, așa cum au subliniat alții, aderarea la ele și indexarea acestora, prin definiție, nu va fi aproape nici la fel de rapidă ca în cazul întregilor.

Vă pot răspunde că în serverul SQL, dacă utilizați un tip de date unic identificator (GUID) și utilizați funcția NEWID() pentru a crea valori, veți obține fragmentări oribile din cauza împărțirii paginilor. Motivul este că atunci când se utilizează NEWID() valoarea generată nu este secvențială. SQL 2005 a adăugat funcția NEWSEQUANTIAL() pentru a remedia această problemă

O modalitate de a utiliza în continuare GUID și int este de a avea un guid și un int într-o masă astfel încât hărțile guid către int. Guidul este utilizat extern, dar int intern în DB

de exemplu

457180FB-C2EA-48DF-8BEF-458573DA1C10    1
9A70FF3C-B7DA-4593-93AE-4A8945943C8A    2

1 și 2 vor fi utilizate în cuplaje și guides în aplicația web. Acest tabel va fi destul de îngust și ar trebui să fie destul de rapid pentru interogare

De asemenea, depinde de ce vă interesează aplicația dvs. Pentru aplicațiile n-tier, GUID-urile / UUID-urile sunt mai ușor de implementat și sunt mai ușor de portat între diferite baze de date. Pentru a produce cheile Integer, unele baze de date suportă un obiect secvențial nativ, iar altele necesită o construcție personalizată a unui tabel de secvențe.

Cheile întregi probabil (nu am numere) oferă un avantaj pentru interogarea și indexarea performanței, precum și utilizarea spațiului. Interogarea directă a DB este, de asemenea, mult mai ușoară utilizând cheile numerice, mai puțin copiați / lipiți, deoarece acestea sunt mai ușor de memorat.

Ați putea folosi un număr întreg care are legătură cu numărul rândului, dar nu este secvențial. De exemplu, ați putea lua cele 32 de biți ale ID-ului secvențial și le rearanjați cu o schemă fixă ​​(de exemplu, bitul 1 devine bit 6, bitul 2 devine bit 15, etc ..). Aceasta va fi o criptare bidirecțională și veți fi siguri că două coduri diferite vor avea întotdeauna criptare diferită. În mod evident, ar fi ușor să decodificați, dacă cineva are timp să genereze suficiente ID-uri și să obțină schema, dar, dacă înțeleg corect problema dvs., doriți doar să nu dezvăluiți prea ușor informațiile.

De ce cuplați cheia primară cu URI-ul dvs.?

De ce nu ai cheia URI să fie ușor de citit de om (sau de neconceput, în funcție de nevoile tale) și pe baza întregului index întreg, astfel încât să obțineți cele mai bune rezultate din ambele lumi. O multitudine de programe de blog face acest lucru, în cazul în care ID-ul expus al intrării este identificat de un "slug", iar ID-ul numeric este ascuns în interiorul sistemului.

Beneficiul adăugat aici este că acum aveți o structură URL foarte frumoasă, care este bună pentru SEO. Evident, pentru o tranzacție acest lucru nu este un lucru bun, dar pentru ceva de genul stackoverflow, este important (a se vedea URL-ul de sus ...). Obținerea unicității nu este atât de dificilă. Dacă sunteți cu adevărat îngrijorat, păstrați un hash de la un bufet într-o masă undeva și faceți o căutare înainte de inserare.

edit: Stackoverflow doesn't quite use the system I describe, see Guy's comment below.

Atât timp cât utilizați un sistem DB cu stocare eficientă, HDD este ieftin în aceste zile oricum ...

Știu că GUID-urile pot fi de lucru cu unele ocazii și vin cu unele interogări deasupra capului, însă din perspectivă de securitate sunt salvatori.

Gandindu-te la securitatea prin obscuritate, ele se potrivesc bine atunci când formează DB-uri obscure și construiesc normalizate DB-uri cu tabele, înregistrări și coloane definite de securitate pe care nu ai cum să le înșelați cu GUID-urile, încercați să le faceți cu ID-uri bazate pe întreg.

Am încercat atât în ​​aplicații web reale.

Opinia mea este că este preferabil să folosim numere întregi și să avem urluri scurte și comprehensibile.

Ca dezvoltator, se simte cam îngrozitor să vezi numere secvențiale și știind că unele informații despre numărul total de înregistrări scapă, dar sincer - majoritatea oamenilor probabil că nu le pasă și că informațiile nu au fost niciodată cu adevărat critice pentru afacerile mele.

Având URL urât urât UUID mi se pare ca mult mai mult de o oprire la utilizatorii normali.