Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.

Primary key INT vs CHAR

[es] :: MySQL :: Primary key INT vs CHAR

Strane: 1 2 3

[ Pregleda: 3161 | Odgovora: 40 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Primary key INT vs CHAR18.04.2021. u 12:07 - pre 35 meseci
Zdravo svima,


Često imam potrebe da pravim tabele gde će primarni ključ biti vidljiv spolja pa nije baš dobro da to bude klasičan auto-increment ID. Razmišljam da to bude neki pseudo-string od 12 karaktera (npr: a99d680e12e6) pa me zanima da li će to da obori performanse kod pretraga? Konketno, da li je i koliko sporiji indeks za CHAR(12) u odnosu na INT?

 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 14:43 - pre 35 meseci
Mislim da PK, ne treba da bude vidljiv spolja ni u jednoj varijanti.
Ako mora, moze da bude enkriptovan, npr. ako ulazi kao url parametar.
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 14:57 - pre 35 meseci
Slažem se sa dejanetom. Primarni ključ treba da služi da jedinstveno identifikuje slog u tabeli.
Ako ti treba da ima neku drugu svrhu onda uvedi prirodni ključ pore PK i koristi prirodni ključ za tu drugu svrhu.



 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 15:05 - pre 35 meseci
Šta bi konkretno dobio time što bih imao dva identifikatora, jedan public jedan private?
 
Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3445

Jabber: djoka_l


+1462 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 15:41 - pre 35 meseci
Šta bi konkretno dobio ako PK nije int nego char?

Prvo osnovno razmatranje: poređenje dva int broja je jedna mašinska operacija. Ako uzmemo da su registri 64-bitni, poređenje 2 stringa dužine 12 su dve komparacija + još jedno grananje - znači 2 operacije viška.
U tabeli sa milion slogova, to znači da ćeš PK koji je int naći posle 20 komparacija, a char(12) posle 40.
To čak nije ni preterano bitno, bitnije je što ćeš morati da pročitaš, možda, 20 blokova iz baze koji sadrže indeks, tako da je broj komparacija nebitan u odnosu na I/O, pogotovo što će neki blokovi biti baferisani.

Indeks nad char(12) će zauzimati do 33% više prostora na disku.

Sve u svemu, neku razliku u pretraživanju nećeš videti, ako tražiš slog sa tačno specificiranom vrednošću polja koje je PK.

Ono što možeš da dobiješ kao poboljšanje je pretraživanje po prefiksu indeksa, recimo LIKE 'abc%' gde će char(12) ubedljivo da pobedi int PK.
Samo što je takvo pretraživanje besmisleno za PK, koji samo treba da bude jedinstvena oznaka sloga, a ne nešto što ima strukturu i neko "dublje" značenje.


Ako je tebi problem to što ne želiš da ti slogovi imaju sekvencu koja može da se pogodi, nemoj da PK bude nešto što ćeš da koristiš za takve stvari.
Recimo, broj kartice (kreditne ili debitne) je 16-cifreni broj, prvih 6 cifara je oznaka banke i tipa kartice, poslednja 2 su kontrolni brojevi.
Ono što je bitno za kartice je da onih srednjih osam ne idu u sekvenci, jer, recimo, ako posle kartice sa brojem 1, a koja važi do marta 2023, izdaš karticu broj 2, malčiciozni softver bi mogao da pretpostavi da je i rok važenja kartice 2 do marta ili aprila 2023. godine. Međutim, broj kartice ni kod jedne normalne banke nije PK.
 
Odgovor na temu

dejanet
Beograd

Član broj: 19240
Poruke: 1181



+835 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 16:14 - pre 35 meseci
@S A J A:

Sto se mog odgovora gore tice, evo sta sam mislio, sta god da se izabere kao PK, pod uslovom da je moranje, kod requesta (ruta, url kod api, web ili mq), pre requesta enkriptovati, pa dekriptovati kod implementacije.
Kod vracanja rezultata, sta god bilo, npr. json, ako je nephodan PK, opet ga enkriptovati... Rezultat toga je da uvek imas enkriptovan pkid na klijentu, a po potrebi dekriptovan PK na server-u za potrebe query-ija.

Daleko od toga da je ovo najbolje resenje, ali je mislim najjednostavnije.
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
dynamic-62-240-24-62.cpe.sn.co.rs.



+1064 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 16:43 - pre 35 meseci
Primarni kljuc string tipa ima smisla ako ima nekog smisla uzeti takav kljuc. Inace idjevi se u relacionim tabelama koriste kao pointeri na druge slogove. Mislim ono treba se smarati pa generisati ako nije prosti
auto inkrement.
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 16:52 - pre 35 meseci
Moze li posasnjenje zasto PK ide van baze? Znam za bar jedam primer u mysql-u PK-a koji nije enkriptovan i ide van (tabela mysql.user ima kompozitni privatni kljuc od dva polja - user i host), ali me zanima use case da taj kljuc ide van.

Vodite racuna da je npr. uuid u biti 128-bitni integer, pre nego sto krenete da "zamisljate" char-ove. Ako vam se ne svidja da bude autoincrement INT, mozete da koristite uuid on je zamisljen za to da bude unique id.

Takodje, kako tacno treba da izgleda struktura tabele da id bude nesto sto treba kriptovati? Opet, cisto me zanima...

Tesko je dati odgovor na pitanje "kako da izvedem ovo", ako ne razumes cemu to sluzi ;)
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

Branimir Maksimovic

Član broj: 64947
Poruke: 5534
dynamic-62-240-24-62.cpe.sn.co.rs.



+1064 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 17:12 - pre 35 meseci
Kljuc ako se prikazuje ne steti osim ako se ne koristi za sql injection :P
no uglavnom select * from users razbije vecinu sajtova ;)
 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 17:16 - pre 35 meseci
Hvala svima na odgovorima, malo smo skrenuli sa teme koja je u osnovi razlika u brzini između indeksiranje INT i CHAR(12) pa smo prešli na usecase...

Probaću da objasnim. U pitanju je web aplikacija za poslovanje (knjigovodstvo i tako te stvari...). I tu postoje razne tabele tipa artikli, partneri, fakture, projekti i štošta drugo...
I recimo, jedna od tabela će biti firma. Znači korisnik kad se uloguje, moći će da otvori firmu (ili više firmi) pa da radi u njima.
Logično u bazi će biti tabela firmi i svaki put kad korisnik napravi neku akciju, uz podatke će morati da ide i ID firme kako bi znao na koju se odnosi.

Na primer: hoće da izlista artikle ili upiše fakturu, mora serveru da prosledi ID firme...
I sad, pošto je tabela firmi zajednička za sve korisnike, malo je glupo da oni kako otvaraju firme dobijaju ID koji je broj 1, 2, 3...

Zato sam i mislio da ID bude neki bezveze string koji nema nikakvo značenje, na primer: 14dda8872b0e, koji bi postavio kao primarni ključ u toj tabeli.
Taj broj generišem preko PHP funkcije bin2hex(openssl_random_pseudo_bytes(6)) i trebalo bi da je solidno jedinstven. Čak i ako dođe do dupliranja i baza odbije insert, ponoviću generisanje i upis i to neće biti problem. Takođe, tako generisan broj ima 4738381338321616896 kombinacija što je više nego dovoljno, zapravo čak i dosta više nego što ima INT. To meni vrši posao.

Tako da, ako već klijent dobija taj ID firme koji posle mora da prosledi u svakom zahtevu, zašto bi onda u bazi imao još jedan ID broj koji bi bio INT i koji nikad ne bi koristio?

 
Odgovor na temu

dusans
Stojanov Dušan
Pančevo

Član broj: 9551
Poruke: 1343
*.dynamic.sbb.rs.



+311 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 18:53 - pre 35 meseci
uniqueidentifier (uuid, guid) ume da bude zahvalan pogotovo kada dođeš u situaciju
da seliš podatke iz jedne u drugu bazu, deliš između sistema, da dozvoliš klijentima da oni dodele id,
da generišeš id pre nego što dođeš do baze, itd... što uopšte nije retkost u praksi.
Prilično su non-guessable, svaka moguća platforma ume da ih generiše, itd...

Jesu nešto sporiji od int-ova ali imaju i svoje prednosti.
Pogotovo vs auto increment gde ne možeš da barataš sa id-em pre nego što si zaista uradio insert u db-u.

Za male tabele (tipa enum i slično) koristim prirodne ključeve (string).
Za radne podatke, ranije int, skorije gotovo svuda uniqueidentifier.
 
Odgovor na temu

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

ICQ: 49345867
Sajt: https://www.twinstarsyste..


+655 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 19:15 - pre 35 meseci
OK, ajde ovako: Imaces, kao ID firme, da budemo optimisti, maksimalno sto hiljada slogova.

Stavi uuid, da te ne boli glava oko toga sta ce da bude. Ne izmisljaj toplu vodu kad postoji standard za to. :) Alternativno, ako zelis da imas jednosmernu vezu SHA224("ime_firme"). Performanse na tom broju slogova ti nece biti problem...
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
Odgovor na temu

vujkev
Beograd

Član broj: 8072
Poruke: 1347
*.dynamic.isp.telekom.rs.



+104 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 21:04 - pre 35 meseci
Citat:
S A J A:
I sad, pošto je tabela firmi zajednička za sve korisnike, malo je glupo da oni kako otvaraju firme dobijaju ID koji je broj 1, 2, 3...


Što je glupo? Svaki korisnik će imati valjda neka određena prava nad svakom firmom i to što zna da postoji ID firme "1" mu ništa ne znači. Valjda ne zasnivaš logiku na tome da je jedina zaštita da korisnik ne zna ID firme.
Naučio sam...
Da je važnije biti ljubazan nego biti u pravu
 
Odgovor na temu

BuzzLightyear

Član broj: 345017
Poruke: 71



+432 Profil

icon Re: Primary key INT vs CHAR18.04.2021. u 22:41 - pre 35 meseci
Citat:
S A J A:
Šta bi konkretno dobio time što bih imao dva identifikatora, jedan public jedan private?


U većini slučajeva trebalo bi da imaš autoinkrement primarni ključ i jednu (ili više) unique kolona. Ako nemaš nijednu unique kolonu, onda verovatno nešto nije u redu. Ovde je pitanje zašto bi imao dva veštačka ključa? Dovoljno je da imaš samo autoinkrement.
 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 00:44 - pre 35 meseci
Citat:
dusans:
uniqueidentifier (uuid, guid) ume da bude zahvalan...


Citat:
nkrgovic:
Stavi uuid, da te ne boli glava oko toga sta ce da bude.


Da, ovo je zapravo neka varijanta uuid-a, samo sam ga "skratio" na 12 karaktera. Mislim da je uuid 32 karaktera bez crtica, to mi deluje nekako mnogo.

Sad je sledeće pitanje, koliko je sporiji indeks CHAR(32) u odnosu na CHAR(12)? ;)

 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12846



+4783 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 01:23 - pre 35 meseci
UUID je binary(16), ne char(32).
 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 01:25 - pre 35 meseci
Citat:
S A J A:
Šta bi konkretno dobio time što bih imao dva identifikatora, jedan public jedan private?


Pogrešno si to razumeo. Nije jedan privatni a jedan javni. Nego je jedan primarni ključ (PK) a jedan je prirodni ključ.

Tehnički gledano definišu se isto: radi se o vrednosti koja mora biti jedinstvena na nivou tabele.

Razlika je u tome što primarni ključ nema i ne sme da ima ama baš nikakvo značenje osim da služi da se identifikuje slog u tabeli i njega određuje sama baza u trenutku kreiranja sloga.

Onog trenutka kada ti zatreba da primarni ključ upotrebiš tako da ima neko značenje to znači da ne treba njega da koristiš nego da uvedeš prirodni ključ. Prirodni ključ je nešto što određuje korisnik baze, bilo tako što ga sam ukucava u bazu ili tako što određuje pravila za nekakvo automatsko generisanje. To se može razlikovati od korisnika do korisnika. Prirodni ključ ima i prednost da njega ne koristiš za povezivanje sa drugim tabelema pa to znači da možeš u bilo kom trenutku da ga promeniš na slogu sve dok je i dalje jedinstven na nivou tabele.

Dobar primer su baš primeri koje si pomenuo: šifarnici komitenata, artikala, radnika i slično. Šifra komitenta, šifra artikla, šifra radnika, to su ključevi koji za korisnika baze mogu i obično i imaju značenje i on ih određuje te su to prirodni ključevi i to ne treba da budu ujedno i primarni ključevi.

Sasvim je realna situacija da korisnik baze u nekom trenutku odluči da promeni način šifrovanja u tabelama u želi da promeni šifre komitenata, šifre artikala, čifre radnika (s obzirom da su to vrednosti koje imaju zančenje on prosto zaključi da mu treba da preorganizuje šifre jer je zaključio da mu postojeća organizacija ne odgovara). To je prilično čest zahtev. Ako su te šifre ujedno i primarni ključevi u nebranom si grožđu jer su ti po njima povezani podaci u raznim drugim povezanim tabelama i menjanje šifre u osnovnom šifarniku znači da to mora da se menja svugde gde se ta šifra koristi. Verovatno to ne bi poželeo ni najcrnjem neprijatelju.

Drugi čest slučaj je da treba da se napravi novi slog za neki entitet ali još uvek nije određena značenjska šifra za entitet. Na primer, na web sajtu se prijavi novu kupac, web sajt prikupi njegove podatke i kreira ga u svom šifarniku kupaca. Onda pošalje te podatke u centralu gde u centralnom šifarniku takođe treba da se kreira taj novi kupac. Tek u centralnom šifarniku se dodeljuje šifra tom novom kupcu. Ako koristiš prirodni ključ kao primarni (šifru kupca), imaš problem jer da bi napravio slog mora da mu se odmah dodeli primarni ključ a ti ga nemaš. Ako je PK beznačenjski možeš odmah da ga dodeliš slogu (autoinkrement na primer) a prirodni ključ može da se dodeli i naknadno.

Slično je, recimo, sa artiklima - zamisli da od dobavljača stigne pun kamion raznorazne robe. Podatke o artiklima imaš ali su šifre artikala šifre koje je odredio dobavljaš, i po pravilu te šifre ti ne možeš da korsitiš nego dodeljuješ svoje. Neke artikle si možda već dobijao ranije pa ih imaš šifrirane ali neke ne. Nema se vremena da se u momentu prijema robe radi i šifriranje (a pošto robu primaju magacioneri oni i ne znaju kako da rade šifriranje) nego se roba prima i umese u bazu sa podacima koji postoje (koristeći beznačenjski primarni ključ za identifikaciju sloga) a tek se naknadno radi šifriranje te robe to jest dodeljuju joj se sopstvene šifre i to se upisuje kao prirodni ključ.

Treći slučaj je autoamtsko generisanje brojeva dokumenata, faktura, opremnica, ranih naloga, ulaza i izlaza magacina i čega sve ne. Brojevi dokumenata se po pravilu određuju po nekoj logici, i to nisu samo proste jednoznačne oznake. Neka vrsta dokumenta može da se kreira na više fizičkih mesta i pri tom, ne mora d azbači da sv amesta imaju uvek pristup centrlanoj bazi nego svako radi sa nekom svojom lokalnom bazom a povremeno radi sinhronizaciju. I sad, kako jedno mesto da dodeli broj dokumenta ako je taj dokument primarni ključ? Nije neizvodivo ali je komplikovano. Ako imaš pored PK i prirodni ključ, koji ćeš PK dodeliti je nebitno,jer je on interni, ali zato prirodni ključ možeš da dodeliš po nekom pravilu, recimo da uvedeš prefiks u broju dokumentakoji određuje loakciju na kojoj je dokument napravljen i tako obezbediš da broj dokumenta bude jedinsten na nivou centralne baze jer svaka će lokacija da koristi svoj jedinstveni prefiks.

U bazi gde su primarni i priodni ključevi odvojeni korisnik baze i ne mora uopšte da vidi i zna za primarne ključeve. On radi sa prirodnjim ključevima koji su njemu bitni i imaju neko značenje. Primarni ključevi su mu obično nepraktični jer su predugi. Zamsili nekoga ko radi sa redom veličine 1000 komitenata a mora da brata sa šiframa dugim 12, 16, 32 ili 64 znaka, zavisi koliko izabereš za primarni ključ. U praksi su mu dovoljna četri znaka. Ili zamisli tek nekoga ko iam hilajde artikala u ifarniku artikaal koji umesto da tim artiklim da neke smislene šifre koje je lako praktično koristiti na kasama, i još koje mogu da imaju neku značenjsku strukturu radi lakše pretrage artikala na kasama, oni moraju da koriste opet neke šifre od 12, 16, 32 ili 64 znaka koje su samo gomila brojeva i slova bez ikakve logike. A njemu je itekako bitna logika u šiframa.

Sve u svemu, kada razdvojiš primarni od pirodnog ključa, trsiš se mnogih problema koji bi te, inače, sačekali i po pravilu te skupo koštali jer ih ne bi predvideo na vreme.


Što se tiče samog primarnog ključa, obuično nema potrebe da uopšte nešto izmišjaš nego korsitiš autoinkrement ceo broj i to je to. Korišćenje karakterinog polja za priamrniključ obično iam smisle tak ako imaš potrebu da ipak daš neko značenje sadržaju priamrnog ključa, ali ne ono koje mu daje korisnik baze nego nešto što ima logoku za tovju apliakciju. Na primer možeš u primarnom ključu kao prefiks da koristiš poslovnu godinu i tako omogućiš fizičko segmentiranje tabele po tom prefiksu, što može znatno da ubrza pristup podacima.

[Ovu poruku je menjao Predrag Supurovic dana 19.04.2021. u 02:50 GMT+1]
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.dynamic.sbb.rs.

Sajt: mysql.rs


+2377 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 04:31 - pre 35 meseci
Citat:
Shadowed:
UUID je binary(16), ne char(32).


128 bita tj 16 bajtova ... sve je to super samo mysql nema uuid funkcije pre 8.0, ma koliko ja savetujem svima da predju na 8.0 i dalje oko 50% raje koristi verzije starije od 8.0

uuid kao pk realno nema prednost, znam da ce sada iljade ljudi da skoci u odbranu uuid-a ali zao mi je to je istina, to je samo jedan veliki hype ..

osnovne prednosti uuid-a koje se pedlaju svuda vec deceniju su
[1] unique values across tables/databases/servers ...
[2] do not expose data
[3] can be generated on the client

sve tri su B00LSH1T

1 i 3 su ista stvar, svodi se na to da nece napraviti 2 ista uuid-a nikad ... e pa prc, oces, neces izmedju servera zato sto je par bajtova uuid-a deo mak adrese ili ssh kljuca servera na kom se generise ali na istom serveru, o da, moguce je da napravis 2x isti, desava se prilicno cesto (tipa bar jednom mesecno) i to ne na nekom "big data" vec na relativno malim bazama od parsto giga, ispod 1T ... a za "across databases/servers..." postoje kompozitni kljucevi koji su laksi za koriscenje i debagiranje i brzi i lepsi i nisu hype, postoje od kad i relacione baze...

2 je tek debilarijum, security through obscurity, ko ne razume nema mu svrhe objasnjavati ..

a da pricamo o negativnim stranama ... za pocetak, 64bitni bigint staje u registar, optimalno koriscenje procesora, ultra brzo skeniranje indexa, citanje, pisanje ... za 128 bita, prc nije duplo sporije nego znacajno vise nego duplo jer vise nista nije optimalno, ni vecina registra, ni l1, l2, l3 kesh, ni ram nista .. teoretski bi mogao da se koristi GPU ali je use-case suvise mali da bi se cimali pa se GPU acceleracija koristi za druge stvari (paralelizaciju FTS-a i agregatne funkcije, naravno pricam o "tamo gde GPU acceleracija postoji", sto opet nije mysql)


UUID je "solution in search of a problem" ... ne koristi ga gotovo nigde (nigde gde je vazno) nijedna velika kuca


da se vratimo na tamu "INT vs CHAR"

- bigint je brzi od bilo kog CHAR-a
- obrati paznju na default karakter set i kolacije, probleme koje mozes da imas tu kod migracije ukoliko se na to ne obrati paznja etc etc, takodje na kolicinu bitova upotrebljenih za kljuc u slucaju razlicitih karatkter setova, bez da spominjemo da razlicite kolacije mogu da uvedu duplicate entry za char pk sto tek moze da dovede do tone problema
- ako ti treba obscurity, md5, sha, sha2, sha256....
- ako ti treba reprezentacija pk-a, vec neko spomenu "prirodni" kljuc (gledaj na to kao na SEO slug na primer)
- to sto se ID vidi u URL-u je nebitno, ako ti to predstavlja problem onda ti aplikacije nije za upotrebu

 
Odgovor na temu

S A J A
Beograd

Član broj: 226539
Poruke: 1904
*.static.sbb.rs.



+421 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 12:09 - pre 35 meseci
Citat:
Predrag Supurovic:
Pogrešno si to razumeo. Nije jedan privatni a jedan javni. Nego je jedan primarni ključ (PK) a jedan je prirodni ključ.

Tehnički gledano definišu se isto: radi se o vrednosti koja mora biti jedinstvena na nivou tabele.

Razlika je u tome što primarni ključ nema i ne sme da ima ama baš nikakvo značenje osim da služi da se identifikuje slog u tabeli i njega određuje sama baza u trenutku kreiranja sloga.


Ovo je sve jasno, samo u mom slučaju nema prirodnog ključa (kako ga već nazivaš). Ovaj presudo-string (ili uuid) nema nikakvo značenje, besmislen je isto kao i INT ID. Služi samo da identifikuje record.

Kad sam mislio da mi treba neki identifikator koji će biti public, nisam mislio na podatak koji će videti korisnik programa. Njemu će se prikazati spisak firmi (kojim on ima pristup) ali naravno da neće videti ID koji je u pozadini. Ali, fakat taj ID putuje u klijent browser i ako se neko potrudi, može da ga vidi.

Naravno, to nije smak sveta jer postoje prava pristupa, ne može svako da pristupi svakoj firmi ali opet, ako pustim da mi ID-ovi idu na klijent, neko može da "izbroji" koliko je novih firmi otvoreno u periodu pa tako da ima neku predstavu kako mi ide biznis... i slično.

U tom kontekstu pričam o ID-u koji je public. Zato sam mislio da umesto auto-numbera stavim neki string ili UUID. Ili, što je neko predložio, da se radi encrypt/decrypt ID broja, sad je samo pitanje šta je bolje sa stanovišta performansi. Jer, uz svaki API zahtev na server će dolaziti ID firme, a tih zahteva će biti dosta. Da li je bolje svaki put raditi decrypt ili u bazi lookup preko string-a/uuid-a.

 
Odgovor na temu

Predrag Supurovic
Pedja YT9TP
Užice

Član broj: 157129
Poruke: 6275

Sajt: pedja.supurovic.net


+1570 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 12:38 - pre 35 meseci
Citat:
S A J A: Ovo je sve jasno, samo u mom slučaju nema prirodnog ključa (kako ga već nazivaš). Ovaj presudo-string (ili uuid) nema nikakvo značenje, besmislen je isto kao i INT ID. Služi samo da identifikuje record.

Kad sam mislio da mi treba neki identifikator koji će biti public, nisam mislio na podatak koji će videti korisnik programa. Njemu će se prikazati spisak firmi (kojim on ima pristup) ali naravno da neće videti ID koji je u pozadini. Ali, fakat taj ID putuje u klijent browser i ako se neko potrudi, može da ga vidi.

Naravno, to nije smak sveta jer postoje prava pristupa, ne može svako da pristupi svakoj firmi ali opet, ako pustim da mi ID-ovi idu na klijent, neko može da "izbroji" koliko je novih firmi otvoreno u periodu pa tako da ima neku predstavu kako mi ide biznis... i slično.

U tom kontekstu pričam o ID-u koji je public. Zato sam mislio da umesto auto-numbera stavim neki string ili UUID. Ili, što je neko predložio, da se radi encrypt/decrypt ID broja, sad je samo pitanje šta je bolje sa stanovišta performansi. Jer, uz svaki API zahtev na server će dolaziti ID firme, a tih zahteva će biti dosta. Da li je bolje svaki put raditi decrypt ili u bazi lookup preko string-a/uuid-a.


Pomenuo su da ti to treba za šifarnik komitenata i šifarnik artikala. Ta dva šifarnika imaju prirodni ključ.

Prirodni ključ je korisniku potreban. Neće on svaki putkad mu treba neki komitent ili artikal da brlja po listama, nego će tražiti da ukuca šifru koju zna i da odmah dobije traženog komitenta ili artikal. U veb šop interfejsu (ako tio pravišp) to nije toliko kritično, ali onoj drugoj strani koja barata sa tim podacima je itekako potrebno.

 
Odgovor na temu

[es] :: MySQL :: Primary key INT vs CHAR

Strane: 1 2 3

[ Pregleda: 3161 | Odgovora: 40 ] > FB > Twit

Postavi temu Odgovori

Navigacija
Lista poslednjih: 16, 32, 64, 128 poruka.