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: 3158 | Odgovora: 40 ] > FB > Twit

Postavi temu Odgovori

Autor

Pretraga teme: Traži
Markiranje Štampanje RSS

nkrgovic
Nikola Krgović
Beograd

Član broj: 3534
Poruke: 2807

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


+655 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 13:26 - pre 35 meseci
Citat:
S A J A:
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.

Ti znas da auto increment increment ne mora biti 1 ? :)

Takodje, ja stvarno ne vidim sto bi radio hash ili bilo sta... Ako ce neko da ti kopa API pozive kroz https, taj ce da ih iskopa. Serijalizuj json, pusti kroz https i cepaj. Ne vidim sta tacno moze da dobije neko raspakivanjem tvojih API poziva, ako imas dobro resen auth.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
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 13:31 - pre 35 meseci
Citat:
nkrgovic: Ti znas da auto increment increment ne mora biti 1 ? :)


Jel može da bude random? To bi bilo kul ;)

Citat:
nkrgovic Takodje, ja stvarno ne vidim sto bi radio hash ili bilo sta... Ako ce neko da ti kopa API pozive kroz https, taj ce da ih iskopa. Serijalizuj json, pusti kroz https i cepaj. Ne vidim sta tacno moze da dobije neko raspakivanjem tvojih API poziva, ako imas dobro resen auth.


Ne mora ništa da kopa, može da se registruje kao korisnik i otvori novu firmu i vidi ID preko konzole.
 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12846



+4783 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 14:16 - pre 35 meseci
Citat:
nkrgovic: Ti znas da auto increment increment ne mora biti 1 ? :)

A jos ne mora ni da krece od 1 :)
 
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 22:33 - pre 35 meseci
Citat:
bogdan.kecman:
da se vratimo na tamu "INT vs CHAR"
- bigint je brzi od bilo kog CHAR-a


Hteo sam ovo da izmerim pa sam napravio tabelu sa 2 kolone, INT i CHAR(12). Ovaj prvi je primarni ključ, ovaj drugi ima unique index. 7 miliona redova. U pretrazi nema nikakve razlike u brzini. U oba slučaja query traje oko 30ms. Proverio sam 20 puta i nema razlike.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 22:41 - pre 35 meseci
mnogo je to mali test da bi mogao da izmeris oba kljuca su ti celi u
ramu i oba su malecni

dodatno, kakav ti je to upit koji za PK/UK traje 30ms?
 
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 22:46 - pre 35 meseci
Citat:
bogdan.kecman:
dodatno, kakav ti je to upit koji za PK/UK traje 30ms?


select * from test where id=12345;
 
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 22:55 - pre 35 meseci
Da, kapiram, mnogo sam glup, pošto je server remote, ja sam zapravo merio internet brzinu. Kad se nakačim direktno na server, izađe mi 0.00. Jel ima neka komanda da se preciznije izmeri vreme?
 
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 23:02 - pre 35 meseci
Našao sam neki profajling ali opet ne vidim neku razliku majkumu... ako ovo na 7 miliona redova radi ovako slično, to je meni dovoljno.

Code:

+----------+------------+--------------------------------------------------+
| Query_ID | Duration   | Query                                            |
+----------+------------+--------------------------------------------------+
|        2 | 0.00280050 | select * from test where char12='dd123423423423' |
|        3 | 0.00262300 | select * from test where char12='dd123423423423' |
|        4 | 0.00176075 | select * from test where char12='dd123423423423' |
|        5 | 0.00118125 | select * from test where char12='dd123423423423' |
|        6 | 0.00047325 | select * from test where char12='dd123423423423' |
|        7 | 0.00365100 | select * from test where char12='dd123423423423' |
|        8 | 0.00181625 | select * from test where char12='dd123423423423' |
|        9 | 0.00266225 | select * from test where id=123423423423         |
|       10 | 0.00049075 | select * from test where id=123423423423         |
|       11 | 0.00072550 | select * from test where id=123423423423         |
|       12 | 0.00102425 | select * from test where id=123423423423         |
|       13 | 0.00132925 | select * from test where id=123423423423         |
|       14 | 0.00280775 | select * from test where id=123423423423         |
|       15 | 0.00170150 | select * from test where id=123423423423         |
|       16 | 0.00112100 | select * from test where id=123423423423         |
+----------+------------+--------------------------------------------------+
 
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 CHAR19.04.2021. u 23:05 - pre 35 meseci
Pa ako hash tabela int je brzi za toliko sto ne mora da se hashira nego se uzima gotova vrednost dok char mora da se hasira u int. Mislim da to odradi za nemerljivo vreme tako da mu dodje na isto...
 
Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12846



+4783 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 23:13 - pre 35 meseci
Ne kazem da je ovo dobra stvar ali ako si bas zapeo sa tim sto hoces, mozes ovako:
-Stavi da PK bude int ali nemoj staviti auto increment
-Kada kreiras novu firmu izvuci postojece ID-eve i kreiraj random ID od 1 do 1 000 000 koji vec nemas u listi
-Kada doguras do 10 000 firmi, promeni da ID radi auto-increment krecuci od 1 000 001. Preptostavljam da ti tada vise nece biti bitno :)


Daleko od toga da je najbrze, ali realno, koliko cesto pravis novu firmu? Kada kreiras imaces select ID-ova koji ce u najgorem slucaju imati 10 000 komada. Nalazenje random broja koji nije u toj listi je prihvatljivo brzo.
Evo, na brzinu najjednostavnija varijanta koja generise svih 10 000:
Code (csharp):

List<int> numbers = new List<int>();
Random rnd = new Random();
int newNum=1;
for (int i = 0; i < 10000; i++)
{
     while (numbers.Contains(newNum))
          newNum = rnd.Next(1000000);
     numbers.Add(newNum);
}
 

Se izvrsi za 0.05sec. Dakle, nebitno trajanje. Imas samo onaj select postojecih ID-ova. I taj select ce samo postepeno rasti. Quick and dirty ali eto, raditi ti to sto si hteo, bez da zalazimo u to da li bi trebao :)

A inace mislim da se cimas oko pogresnih stvari.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: Primary key INT vs CHAR19.04.2021. u 23:35 - pre 35 meseci
7M i PK upit mora budu uber brzi, to je, ko sto rekoh, mala tabela ...
int poredjenje do 64bita ce uvek biti brze nego poredjenje karaktera,
posebno sto imas razliku u velicini, bigint je 64bita iliti 8 bajtova,
tesko ces ici sa char[8] obicno ces da ides sa dosta vise ... najcesci
pk su char[20] iz nekog mog iskustva kada su char[] pk to je vec sad
poredjenje 2 broja koja staju u registar vs memcmp 20 bajtova + kao sto
rekoh moguci problemi sa kolacijama i karakter setovima

inace nije ti fer poredjenje posto innodb razlicito tretira PK i taj
tvoj unique key jer je PK clustered index koji gadja direkt page gde se
nalazi data, sa druge strane taj unique index u sebi sadrzi i PK tako da
bi pravo porodjenje bilo 2 tabele sa istom datom samo u prvoj index int
u drugoj char .. no, da, na tu velicinu potupno je nebitno

procitaj https://dev.mysql.com/doc/refman/8.0/en/innodb-index-types.html

@shadowed ahhahahhah pa lakse mu je da stavi auto_increment_increment na
50 ili tako nesto :D
 
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 CHAR19.04.2021. u 23:42 - pre 35 meseci
"bogdan:"int poredjenje do 64bita ce uvek biti brze nego poredjenje karaktera, "

To ako je indeks binarno stablo ako je hash tabela onda je upit O(1) tako da nema veze...

edit: pardon ne binarno stablo, nego btree posto to baze koriste.
 
Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.com
Via: [es] mailing liste

Sajt: mysql.rs


+2377 Profil

icon Re: Primary key INT vs CHAR20.04.2021. u 00:34 - pre 35 meseci
hash je uzasno specifican slucaj, ne podrzava range query, ne podrzava
"delove" composity key-a, ne postoji mogucnost pretpostavke velicine
rezultata pa je i cost base optimizer nemoguc, ne mozes da imas
multivalued index kao hash etc etc ...

jos ako uzmemo da je u pitanju mysql HASH index je podrzan samo u
in-memory SE  (memory i ndbcluster) koje sigurno nece koristiti, sto ce
reci innodb i myisam ne podrzavaju hash tako da prica o toma kako bi
hash radio kada bi bio podrzan prilicno nebitna u ovom slucaju ...
fraktalni indexi imaju jos bolje ponasanje u mnogim slucajevima al ne
rade na mysql-u (tokudb sa druge strane...)
 
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 CHAR20.04.2021. u 08:10 - pre 35 meseci
Po meni je i dalje jako glupo komplikovati.... Stavis int (big int) za primarni kljuc, auto increment. Ostavis i auto increment increment na 1. Nije problem sad, bice problem kad budes nesto dodao za 4 godine, pa ide join tri tabele po PK-u....

U API pozivu, umesto po ID-u firme trazis po maticnom broju ili PIB-u. Oba polja imas u tabeli gde drzis podatke o firmi, oba su isto integer, po oba ces, skoro sigurno, imati index. I dalje ne kapiram taj security trough obscurity, ali eto, po meni najprirodnije resenje, ubaci u API nesto sto nije ID iz baze i resio si.
Please do not feed the Trolls!

Blasphemy? How can I blaspheme? I'm a god!'
 
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 CHAR21.04.2021. u 05:07 - pre 35 meseci
btw super txt koji je vlad napisao, treba procitati: https://vladmihalcea.com/clustered-index/
 
Odgovor na temu

mjanjic
Šikagou

Član broj: 187539
Poruke: 2679



+690 Profil

icon Re: Primary key INT vs CHAR21.04.2021. u 11:39 - pre 35 meseci
Neko pomenu Natural Key, ako je PIB jedan od podataka, a u pitanju je int i mora biti jedinstven za svaku firmu, onda on može da se koristi za sve na front-u, tj. PK i ako postoji, ne mora da se prosleđuje eksterno, već samo interno da se koristi ako uopšte za tim ima potrebe.
Blessed are those who can laugh at themselves, for they shall never cease to be amused.
 
Odgovor na temu

S A J A
Beograd

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



+421 Profil

icon Re: Primary key INT vs CHAR21.04.2021. u 12:05 - pre 35 meseci
Ako postoji natural key, to nije nikakav problem, samo što u mom slučaju on ne postoji. Ovo nisu firme u smislu pravih registrovanih firmi, niti je u pitanju striktno Srbija, ti možeš da se uloguješ pa da otvoriš "firmu" koja recimo još nije registrovana, nekakav tim, startup, klub, versku zajednicu, politički pokret, bandu, štagod... Šta je u svemu tome natural key? Nema ga. Meni treba običan ID za identifikaciju ali pošto je sistem client-server, ne bih hteo da autonumber ide na clijent. Zato sam i mislio da to bude neki besmislen string. Koliko sam primetio, na 7 miliona slogova nema nikakvog pada u performansama tako da je to meni dovoljno. Plus, neće upit po tome biti toliko čest, jednom kad nađem ko je u pitanju, stavim ga u memory keš i svaki sledeći zahtev neće ni dolaziti do baze.
 
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 CHAR21.04.2021. u 14:21 - pre 35 meseci
Citat:
S A J A: Ako postoji natural key, to nije nikakav problem, samo što u mom slučaju on ne postoji. Ovo nisu firme u smislu pravih registrovanih firmi, niti je u pitanju striktno Srbija, ti možeš da se uloguješ pa da otvoriš "firmu" koja recimo još nije registrovana, nekakav tim, startup, klub, versku zajednicu, politički pokret, bandu, štagod... Šta je u svemu tome natural key? Nema ga. Meni treba običan ID za identifikaciju ali pošto je sistem client-server, ne bih hteo da autonumber ide na clijent. Zato sam i mislio da to bude neki besmislen string. Koliko sam primetio, na 7 miliona slogova nema nikakvog pada u performansama tako da je to meni dovoljno. Plus, neće upit po tome biti toliko čest, jednom kad nađem ko je u pitanju, stavim ga u memory keš i svaki sledeći zahtev neće ni dolaziti do baze.


Ja bih ipak rekao da ti tu samo ne vidiš prirodni ključ.

Recimo ovako: prirodni ključ uvek postoji. To je ključ koji jednoznačno određuje entitet koji je opisan slogom. Primarni ključ je ključ koji određuje sam slog.

Interesantno mi je da ti ne vidiš problem koji sam sebi praviš tako što insistiraš da ne postoji prirodni ključ u toj tvojoj tabeli, ali ti ne odgovarakako se generiše primarni ključ pa bi to da prilagođavaš.

Odvoj ih. Pusti primarni ključ da radi svoj posao a uvedi prirodni ključ koji ćeš da oblikuješ kako god da ti odgovara i rešio si problem. Ako ti se i desi da posle nekog vremena ustanoviš da način kako kreiraš prirodni ključ baš i nije najbolji, uvek možeš to da promeniš a da to uopšte ne dotiče arhitekturu cele baze jer se ona oslanja na primarni ključ.

Čak i ako ostaneš pri tom da ti odgovara da sadržaj primarnog ključa može da ima ulogu prirodnog ključa onda napravi da tako i bude - koristi sadržaj primarnog ključa kao prirodni ključ, ali to su i dalje dva ključa. Prirodni ključ ne mora da bude stvarno polje u tabeli, to može da bude i izračunato (calculated) polje.

 
Odgovor na temu

S A J A
Beograd

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



+421 Profil

icon Re: Primary key INT vs CHAR21.04.2021. u 14:50 - pre 35 meseci
Ok, znači predlažeš da imam klasičan INT autonumber PK koji bi bio u tabli i ničemu ne bi služio, i da napravim poseban prirodni ključ koji je recimo CHAR(12), npr. "14dda8872b0e" koji bi se koristio u komunikaciji sa klijent aplikacijom? Pošto bi zahtevi od strane klijent aplikacije dolazili samo sa tim prirodnim ključem i pretraga bi radila po tome, šta konkretno dobijam time što imam dve kolone za identifikaciju a realno mi treba samo jedna?
 
Odgovor na temu

madamov
Milan Adamov
vlasnik
Adamov Konsultacije d.o.o.
Beograd, Srbija

SuperModerator
Član broj: 21939
Poruke: 4413
*.dynamic.sbb.rs.

Sajt: www.adamov.rs


+138 Profil

icon Re: Primary key INT vs CHAR21.04.2021. u 16:09 - pre 35 meseci
Ako ćeš ikada da sinhronizuješ baze, onda uzmi 128-bitni integer, ne znam za MySQL, u mom alatu postoji tip UUID, uštedećeš sebi mnogo muke kada jednog dana bude trebalo da nešto sinhronizuješ.
 Certified Trainer Mojave 101 macOS Support Essentials 10.14
http://www.adamov.co.rs http://milan.adamov.rs http://www.infinitum.rs
 
Odgovor na temu

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

Strane: 1 2 3

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

Postavi temu Odgovori

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