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?

Întotdeauna am preferat să folosesc numere întregi ca chei primare în baze de date, pentru simplitate și viteză (presupusă). Dar, atunci când folosiți o schemă de adrese URL REST sau similară cu Rails pentru instanțe de obiecte, aș fi terminat cu adrese URL ca acesta:

http://example.com/user/783

Iar presupunerea este că există și utilizatori cu ID-uri de 782, 781, ..., 2 și 1. Dacă presupunem că aplicația web în cauză este suficient de sigură pentru a împiedica persoanele care intră în alte numere să vadă alți utilizatori fără autorizație, simpla cheie secundară atribuită secvențial, de asemenea, "scurge" numărul total de instanțe (mai vechi decât acesta), în acest caz utilizatori, care ar putea fi informații privilegiate. (De exemplu, eu sunt utilizator # 726 în stackoverflow.)

Ar fi o soluție mai bună UUID / GUID? Apoi aș putea configura astfel de adrese URL:

http://example.com/user/035a46e0-6550-11dd-ad8b-0800200c9a66

Nu este exact succint, dar sunt mai puține informații implicite despre utilizatorii expuși. Sigur, se simte "siguranța prin obscuritate", care nu reprezintă un substitut pentru o securitate adecvată, dar pare puțin puțin mai sigură.

Este avantajul care merită costul și complexitatea implementării UUID-urilor pentru instanțele de obiecte adresabile web? Cred că aș vrea să folosesc în continuare coloane întregi ca PK-uri de baze de date doar pentru a accelera conexiunile.

Există, de asemenea, problema reprezentării în baza de date a UUID-urilor. Știu că MySQL le stochează ca șiruri de caractere de 36 de caractere. Postgres pare să aibă o reprezentare internă mai eficientă (128 de biți?), Dar nu am încercat-o eu însumi. Oricine are vreo experiență în acest sens?


Actualizare: pentru cei care au întrebat despre utilizarea doar a numelui de utilizator în adresa URL (de exemplu, http://example.com/user / yukondude ), care funcționează bine pentru instanțe de obiecte cu nume care sunt unice, dar ce zici de zilioanele obiectelor de aplicații web care pot fi identificate numai prin număr? Comenzi, tranzacții, facturi, nume duplicate, stackoverflow, ...

0
fr hi bn

14 răspunsuri

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ă.

0
adăugat

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.

0
adăugat

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ă.

0
adăugat
@dah solicitantul menționează utilizarea acestuia în cadrul adresei URL din întrebare.
adăugat autor Brian Lyttle, sursa
Acest lucru nu este posibil, nu este necesar să afișați uuid-ul în url.
adăugat autor davidahines, sursa

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.

0
adăugat
base64? Dacă nu aveți un tip de date nativ pentru UUID, aruncați liniuțele și lipiți în byte (32). Probabil că va fi mai rapid decât codarea / decodarea la / de la base64 atunci când aveți nevoie de UUID.
adăugat autor CMircea, sursa

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?

0
adăugat

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 ...

0
adăugat

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.

0
adăugat

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.

0
adăugat
Este o dovadă anecdotică care susține teoria matematică conform căreia asocierea și indexarea întregilor vor fi mai rapide decât șirurile lungi (ish).
adăugat autor Adam Tuttle, sursa
Cum este chiar acest răspuns.
adăugat autor davidahines, sursa
Dacă ați putea oferi mai multe detalii despre locul în care ați văzut acest lucru, ar fi de ajutor. Dimensiunea DB / tabele? DB backend? Modelul de acces (ce a arătat interogarea) ... etc?
adăugat autor Garen, sursa

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

0
adăugat

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.

0
adăugat

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.

0
adăugat
Nu cred că intenția întrebării a fost să aibă o modalitate sigură de a utiliza UUID-uri. În măsura în care am înțeles că subiectul a fost consecințele practice ale acestei decizii. Și schema dvs. nu adaugă nici o securitate și este o risipă de cicluri CPU!
adăugat autor Patrick Cornelissen, sursa

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.

0
adăugat
Stack Overflow indexes pe ID și nu pe slug. Încercați să schimbați melcul din partea de sus a paginii și apăsați pe Enter. Acesta vă va redirecționa la adresa URL canonică pentru această pagină, bazată pe codul de identificare (5949) și ignorând mesajul "slug". Pe server, compară slug cu gunoiul stocat / generat. Dacă nu același lucru returnează un 301. Cu toate acestea, constată că prin căutarea pe ID (5949).
adăugat autor Guy, sursa
Multumesc pentru clarificare!
adăugat autor Jonathan Arkell, sursa

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.

0
adăugat

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.

0
adăugat
Vă mulțumim pentru această opinie. Am cercetat folosind UUID-urile ca chei primare cu toate dezavantajele sale posibile pentru zile până când mi-am dat seama că singurul avantaj (ascunderea informațiilor despre afaceri) nu merită, în cazul meu.
adăugat autor Jan-Philip Gehrcke, sursa
JavaScript, România - Moldova
JavaScript, România - Moldova
328 participanți

Comunitatea Română JavaScript: github.com/js-ro Pentru confort, opriți notificările. Parteneri: @node_ro, @php_ro, @python_ro, @seo_ro, @RomaniaGroup, @ai_ro, @Grupuri_IT Offtop: @holywars_ro Joburi: @js_jobs_ro Sponsored with ❤️ by ciupacabra.com