13 cifara integer ti treba ... ja licno ga cuvam razdvojeno prvih 7 cifara u jednom intu i ostalih 6 u drugom (posto onda lakse vadim datum rodjenja i te gluposti)

Hmm...A zasto mi izbacuje gresku kad stavim 13 cifara int.

Sad sam iskljucio taj komp, ali pise nesto kao too long...a ukucam tacno 13 cifara, tek kad smanjim na 10 (int(10)) i upisem 10 cifara radi?
Znaci jmbg int(13) i upisem 13 cifara dobijam gresku, a int(10) i 10 cifara radi...

E jel ima tu neki longint? Nisam gledao.

HVALA na odg. u svakom slucaju.

zato sto je obican integer 4 bajta, znaci -2147483648 do 2147483647 ili ako koristis unsigned onda 0-4294967295 sto znaci da ne moze da zapamti 13 cifara broj, moras da koristis BIGINT koji je 8 bajtova (-9223372036854775808 do 9223372036854775807 odnosno 0 do 18446744073709551615 u slucaju unsigned)

u svakom slucaju ti je BIGINT (8 bajtova) bolje resenje nego CHAR(13) (13 bajtova)

A sta se desava sa pocetnom 0 kod jmbg ako se koristi int?
Slucaj: 0101970....?

znas tacno koji je format JMBG-a .. svaki integer generalno parsiras od "pozadi" no u svakom slucaju tu dobijas nulu na toj poziciji

Takođe, može i DECIMAL(13,0) koji bi zauzimao 6 bajtova (od MySQL 5.0.3 na ovamo). A što se tiče nule, koristi ZEROFILL.

HVALA to je to.

sa decimal i "brojem bajtova" nemoj previse da racunas posto to moze da se promeni u nekom trenutku .. ako se dobro secam na innodb pluginu (5.5 i dalje) je opet 8 bajta ...\

sto se zerofill tice, to ti ima veze samo u samom cli-u kako izgleda (i definise polje kao unsigned) nece mu dodat nule u njegovom klijentu posto ce isti dobiti broj pa sam mora da se postara oko ispisa

Kako radite proveru ispravnosti JMBG? Funkcija je vezana za svaku cifru
pojedinačno stim da je 13-tacifra kontrolna. Meni je logičnije da
ga čuvam kao text(13). Lakše je izdvojiti cifru kao karakter i
konvertovati u numeričku vrednost nego iz nekog integera izdvajati cifru
po cifru i još voditi računa o popuni vodeće nule.

Pa, nije preterano tesko ni izdvajati cifre. Evo ti primer u C#-u (mozda postoji i bolje resenje, ovo sam na brzaka :)):

@Shadowed

Svaka ti cast :)

Slažem se da je u C, C++ i C# lako to odraditi, ali nije tako u svim
programskim jezicima. I dalje ću koristiti podatak tipa string. Nema
provere da li ima vodeće nule, u većini jezika je prirodno izdvajanje
dela stringa. Važi čak i za uskladištene procedure. Kada uhvatim malo
vremena pokušaću i tu varijantu sa integer-ima a do tada sam i dalje za
podatak tipa string.

mkaras, programski jezik koji nema modulo i deljenje nije programski jezik ... a nesto ne verujem da pises aplikacije u asembleru ... ne postoji "vodeca" nula, kada iz bilo kog integera trazis cifru na toj lokaciji dobices nula ako je tu nula .. dakle problem vodece nule ne postoji .. izdvajanje dela stringa uopste nije prirodno "za sve jezike", cak naprotiv, sve string funkcije trose ogromne kolicine resursa (sto memorije sto vremena, tj cpu ciklusa)... sto se tice stored procedure-a ista prica...

naravno sve se svodi na to da li ti je bitnije da optimizujes to maximalno (i ustedis tih 5 bajtova po slogu, i tih par procesorskih taktova u obradi) ili ti je bitnije da optimizujes svoje vreme i iskoristis string funkcije pa ti kod izgleda "lepse" i pise se 10 minuta krace .. na bazi od 10000 slogova, potpuno je svejedno

Ovaj primer upravo dodaje vodecu nulu. Moze se napraviti i opsta funkcija koja izdvaja cifre iz proizvoljnog broja sa proizvoljnim brojem vodecih nula.

Voleo bih da vidim stored procedure koja je tako napisana. Čini mi se da
je za validaciju unosa ipak normalnije da se koriste resursi baze sa
pripadajućim SQL jezikom nego validacija na nivou aplikacije. Ja do sada
nisam imao problema kada tretiram JMBG kao string pa čak i kada u tabeli
ima mnogo više od tih desetak hiljada slogova. Kada budem imao vremena
probaću i opciju sa int-ovima.

Zavisi kako hoces da dobijes rezultat. Ne moze se napraviti direktno ekvivalentan kod jer SQL nema nizove.

Inace, svakako treba imati validaciju u bazi kako bi zastitio bazu ali je za dobru aplikaciju potrebno imati i u aplikaciji kako bi se koristnik odmah upozorio i stedeli pozivi bazi.

Zamislite JMBG na primer: 0907987510016
Ako je int bice 907987510016, sto nije 13 cifara. Ja bi se tu ipak drzao string-a u programskom jeziku, a VARCHAR(13) u SQL-u.

Kakve veze ima? :)
Onaj kod koji sam dao daje 13 cifara, nezavisno da li jmbg ima nulu na pocetku ili neku drugu cifru.

Ja bih ipak string tip. Desavalo mi se da se dvoumim u nekim slucajevima , a na kraju se ispostavi da je dobro sto sam to uradio .
Pojavi se "stranac" u aplikaciji sa svojim "jmbg-om" ili id-ijem koji osim brojeva sadrzi i karaktere :)

Ili dodje kinez bez JMBGa, a ti stavio da JMBG bude primarni kljuc :)

fino je što razmišljate glasno, ali prvo razmislite.

kada krojite bazu imate projektni zadatak. Ukoliko je potrebno polje JMBG valjda se podrazumeva ko bi se tu upisivao. Logika efikasnosti kaže da je potrebno upisati u što manje memorije. Dakle ili produženi INT ili char(13) - izbegavajte varchar za ovu namenu.
Ne vidim šta je problem sa INT-om, ionako se neka druga aplikacija stara o prikazu i proveri podataka.

Ukoliko imate i kineze, onda je JMBG neobavezan podatak...

U svakom slučaju negde treba uštedeti na prostoru, a negde ne može. U principu vodite računa o širini podataka...

To onda nije jmbg :) A i tada pada u vodu prica o validaciji jmbg-a od koje je i krenulo ovo oko tipa podatka.

Pa da... lepo uštediš 5 bajtova po JMBG-u i svima koji koriste podatak lepo kažeš da napišu funkciju za formatiranje a oni se svi oduševe što moraju to da urade.
Što bi bilo prosto kad može komplikovano ;)

Fora je u tome sto ne znam u pocetku da li cu imati i kineze (stigne novi zahtev za izmenom u aplikaciji)
A u projektnom zadatku stoji da je polje obavezno kao i u celoj funkcionalnosti aplikacije
Koje bagove i ispravke treba da prouzrokuje nullable jmbg polje ... al dobro ..

E onda se pitas sta je bolje kod takvih izmena ..ustedeti po par bajtova na slogu pa onda potrositi sate vremena
da se fuinkcionalnost izmeni ili "ukrasti" jos par MB/GB vise storage i zavrsiti sve u planiranom roku ..

A sigurno je da cu pre voditi racuna i dosta rigorozniji biti koliko app trosi RAM memorije i CPU ciklusa
nego da li ce potrosit par MB storage-a za neko polje danas je manje vise nebitno ...


Nije sija nego vrat . Samo sto ga stranci zovi id a mi jmbg...
Tacno , onda nema validacije nego samo treba da bude unique .

EDIT :
Cak i ne moras da skidas validaciju , samo upozoris korisnika da JMBG nije po "naski"
ali mu omogucis da nastavi sa unosenjem tj. sa radom ..





_{[Ovu poruku je menjao deerbeer dana 14.04.2011. u 11:39 GMT+1]}

Mislim da u Srbiji kod starijih ljudi postoje JMBG brojevi koji nemaju veze sa datumom rodjenja.

Eto dobrog primera - stranci ;) S obzirom da se JMBG nigde ne racuna... nego je statican... "nesto".... najbolje je varchar.
Ne zaboravite da je programiranje 80% predvidjanje mogucih situacija.... i po pravilu te zezne neki %.

Ako dodje kinez, lepo promenis polje JMBG u JBG-a i svi mirni :)

milane, varchar NIKAD nije dobro resenje za ovaj problem

Ako treba da snimaš VATIN onda napravi još jedno polje za to. Ako treba da snimaš SSN onda napraviš posebno polje i za to.

Ali snimati SSN, JMBG, VATIN, PIB i bilo koji drugi sličan podatak u jedno polje nije dobra ideja, naročite ne kao primarni ključ.

Za svaki slučaj da napomenem:
Nemoj stavljati PRIMARY KEY na to JMBG polje.
U Srbiji postoji 100k duplikata JMBG-a.
I nepoznat broj ljudi kojima nikad nije ni dodeljen, niti će biti (?!?)

Nije mi jasan tako decidiran Bogdanov stav. Kod mene u bazi, matični broj je VARCHAR2(13). Osim JMBG-a tu se nalaze i matični brojevi pravnih lica (7 ili 8 cifara), matični brojevi preduzetnika, generisani matični brojevi za pravna i fizička lica koja nemaju matični broj.

Problem sa VARCHAR2 je u tome što mora da se kontroliše da li su uneti znaci van opsega 0-9
Problem sa NUMBER ili INTEGER formatom je to što mora da se pazi na gubitak vodeće (ili vodećih) nule, naročito, ako kao u mom slučaju, nisu svi podaci obavezno iste fiksne dužine.

Po meni INTEGER tip je dobar samo ako nad njim samo treba da se obavljaju neke aritmetičke operacije, inače je VARCHAR2 sasvim odgovorajući. Gubitak nekoliko bajtova po slogu je minoran ako imaš 150 hiljada lica u bazi od 3TB finansijskih promena...

Ukoliko si bas zapeo da ne koristis int, u redu, ali zasto ne koristis Char(13) umesto varchar?

ako je to jedino sto nije jasno onda smo na konju.... bogdan ima decidiran stav zato sto zna kako je koji tip podataka implementiran unutar mysql-a i sta koliko kosta ... mozes ti da cuvas to i u blobu sto se bogdana tice, ali ako pricamo o "dobrom" resenju, varchar nikad nije dobro resenje. Ako bas hoces da koristis karakter tip onda koristi char(13).



kao sto rekoh, mozes i blob da koristis nije problem, pitanje da li je to "dobro resenje" ... diskutabilno je to sto u jednom polju cuvas jmbg, maticni broj i "generisani" id .. ne mora da bude pogresno - denormalizacija baze ume da bude vrlo korisna u mnogim slucajevima tako da "dobro" resenje u ovom slucaju uvek zavisi od samog zahteva, mada opet ovde char(13) pravi mnoooooooooooogo bolju tabelu nego varchar(13)... bitno je cuvati bajtove, ali za polja nad kojima imas index je mnogo vaznije da su poznate duzine, posebno u slucaju da ti u 90% slucajeva zauzimaju tu max duzinu, kolicina bacenih bajtova u mnogome zasenjuje brzinu koja se na taj nacin dobija... da ne spominjemo da ako su sva polja u tabeli poznate duzine tabela ima staticki format te su indexi brzi...




ne postoji "vodeca nula" kao problem.... ako to vidis kao problem imas neki znacajan problem na drugoj strani



uzmi u obzir da je porednjenje dva integera znacajno brze od poredjenja dva varchar-a (skoro pa za red velicine), onda uzmi u obzir koliko poredjenja mora da se napravi u drvetu da bi se uradio jedan PK select...

Obrati paznju da ovo sve ima veze samo sa MySQL-om ... nemam ideju kako interno ove operacije obavlja npr oracle i da li to pravi bilo kakvu razliku ... za mysql, i myisam (posebno) i innodb razlika je primetna

Ja bih rekao da ne postoji univerzalno rešenje i sve zavisi od tipa aplikacije. Iskreno, radio sam sa malo aplikacija gde bi performanse bile toliko kritične da bih išao na takve egzibicije da JMBG čuvam kao dva inta. A opet, u mnogo slučajeva mi se dešavalo da nešto što su me u početku ubeđivali da može da bude samo broj kasnije dobije i neki karakter ili da promeni dužinu. Tako da verujem da bih i ja koristio varchar osim ako aplikacija stvarno nije takva da zahteva vrhunske performanse.

Više puta sam radio aplikaciju za jedno tržište koje je posle bilo potrebno prebaciti na drugo tržište gde su drugačija pravila, pa mislim da bi optimizacije ovakvog tipa donele više štete nego koristi. Uostalom, nije tako nemoguće da država u nekom trenutku promeni format JMBG-a.

Mogao je neko pre 10 godina istom logikom da napravi aplikaciju gde će registarski broj auta biti dva polja - jedno tipa char(2) za registraciono područje i jedan int za ostatak, i to bi sa stanovišta performansi, zauzeća diska.. sigurno bilo bolje nego neki varchar. Ali takva aplikacija bi danas bila u velikom problemu kada se format tablica promenio.

Tako da se ja iskreno retko kad odlučujem na optimizaciju na uštrb fleksibilnosti, osim ako to nije baš neophondo. Za većinu aplikacija s kojim radim to nema mnogo smisla.

cak i u tom slucaju varchar je pogresan tip podataka i bolje je da koristis char.

sto se tice "prebacivanja aplikacije na drugo trziste" - alter table nad praznom tabelom traje "0.00" sekundi a pored toga koji je format personalnog id-a moraces jos mnogo sta da lokalizujes tako da je cuvanje broja kao karakter zato sto ce mozda da se sutra prodaje i u kini besmislen.... isto kao i varijanta "mozda ce sutra neko da doda slovo u jmbg" - ako doda onda ces da uradis jedan alter i vozis dalje svejedno moras da prepravis sve forme koje sluze za validatizaciju tog unosa tako da je potpuno svejedno da li ces imati taj jedan alter viska .. posebno sto je sansa da se to desi izmedju mala i nikakva jerbo da bi id morao da uvede i ime morali bi da imamo regiju gde se radja vise od 100 komada dece dnevno ili tako nesto ... mene bi obradovalo ali ..

ako baza ima par hiljada slogova onda imas taj luksuz - obicno baze imaju malo vise slogova

Bogdane, ako je to problem sa performansama na MySql onda razumem tvoj stav, ja radim uglavnom na Oracle bazi.
Nije mi jasna razlika između CHAR i VARCHAR2 tipa na MySql, na Oracle bazi CHAR je fiksne dužine, te bi morao da bude blank paded za podatke koji su kraći od 13.

Što se tiče pretrage po indeksu, možda je nešto brži INTEGER index nego VARCHAR2, ali na Oracle bazi ne postoji u bazi INTEGER tip nego je on izveden od NUMBER, tako da sumnjam da se tu nešto dobije (u PL/SQL postoje integeri koji se lepo koriste u brojačima u petljama, ali prilikom upisu u bazu oni se konvertuju u NUMBER).

Najbitniji razlog zašto VARCHAR2 u Oracle bazi - JMBG se jednom upisuje (i kontroliše po modulu), a koristi se hiljadama puta. Da bi se VARCHAR2 tip podatka prikazao na ekranu ili na štampi, nema nikakve konverzije, ali INTEGER moraš svaki put implicitno ili eksplicitno da konvertuješ u niz ASCII znakova da bi ga ispisao, pri tom moraš da vodiš računa u formatu da ne bi propustio da ispišeš vodeću nulu, ako je ima).
Sa druge strane, nema gubitka kod pretrage po indeksu (NUMBER podatak zauzima maksimalno 19 bajtova u Oracle bazi, a JMBG 13).

Pazi, ja imam slučaj web aplikacije koja je počela da radi na jednom (našem tržištu) da bi u nekom trenutku počeli da radimo i sa firmama sa drugih tržišta. Dakle, ne moram da imam praznu bazu ako počinjem sa novim tržištem.
OK, u toj aplikaciji i nemam JMBG ali imam podatke kao što su računi, poreski brojevi i matični brojevi firmi. Za svaki od ovih podataka bi što se tiče Srbije mogao da koristim int ali kad uzmem i ostale zemlje onda bih imao problem pošto svaka od zemalja ima neke specifičnosti. Nit je dužina ista, niti su sve brojevi (Bugari npr koriste IBAN za račune, a oni imaju karaktere). Opet, u svakoj od ovih zemalja ima 10-30000 firmi, pa ni veličina tabele nije problem. A opet, svi ovi podaci se najčešće koriste za prikaz (izveštaji i sl) i ne radi se često pretraga po njima, pa ni tu nemam problem.


Mislim da bi za većinu aplikacija slična priča bila i za JMBG, sem ako ne pravim aplikaciju gde bi potencijalno svi građani Srbije bili u bazi. Za većinu aplikacija mislim da to ipak nije slučaj.


Zato kažem, sve zavisi od slučaja do slučaja. Ja npr. u većini aplikacija IP adresu čuvam kao varchar jer mi treba samo za reporting. Opet, skoro sam radio aplikaciju koja treba da loguje IP adrese i gde potencijalno može da ih bude jako puno, a znam da ću pretraživati po njima, i tu sam bez razmišljanja uzeo bigint. Mislim da bih isto razmišljao i kada je JMBG u pitanju da je aplikacija takva da mogu da očekujem probleme sa performansama zbog količine podataka. Ali ako se radi o zaposlenima jedne firme ili slične vrste aplikacije, mislim da to nema smisla.

dakle, da ponovim, da vezano je za MySQL ... posto internals orakla ne znam ni 1% koliko znam MySQL.




razlika je ista sto se toga tice i na mysql-u i na oracle-u .. varchar je varijabilne duzine. ono zasto je varchar "sporiji" na mysql-u je zato sto ako nije fixne duzine "127mi index se ne nalazi na 127*duzina lokaciji u ram-u" nego moras da prodjes kroz celu listu sa ->next->next->next da bi dosao do 127mog clana. da ne spominjem da ako tabela nema polja varijabilne duzine tabela je staticke sirine pa je i lokacija 127mog sloga u tabeli na 127*duzina sloga lokaciji ... etc etc ... sve to kosta mnogo vise nego da mu kazes da je CHAR(13) i dobijes staticko polje ... bacices ionako samo par bajtova zato sto ces imati tih par slogova koji imaju "pogresan jmbg ili nesto umesto istog". Kao sto rekoh, ne znam oracle toliko u detalje ali ako se dobro secam oracle se uvek ponasao kao da ima polja varijabilne duzine tako da je njemu isti djavo dal je varchar ili char jer on uvek koristi "goru" varijantu (nista lose od strane orakla, u enterprise aplikaciji ce u 90% slucajeva moguca optimizacija sa statickim kolonama biti nemoguca tako da za oracle tih 10% predstavljaju nebitan border case, gde mysql koji je prvenstveno bio za male brze baze 90% svog bitisanja zasniva na tom border case-u ... u medjuvremenu se mysql prosirio van te male nise ali su ove moguce optimizacije ostale i dalje i ma koliko sada vise nisu u toj meri znacajne i dalje predstavljaju znacajnu mogucnost optimizacije ...)




znam ... evo i drizzle a i dosta drugih baza izbacuje razlicite numericke tipove i ostavlja samo number ... no to je uglavnom zato sto su korisnici debili a ne zato sto je to "bolje". Zato sto imamo korisnike koji ne mogu da shvate koja je razlika izmedju double i decimal mi resimo da ukinemo sve to i kazemo "to je kume broj, mojne se zanimas koliko bajtova, kolika preciznost.. komplikovano je to za tebe" .... to sto "ima samo number" je kao kada mi VB kliktaci pricaju kako su vajni programeri i celo programiranje spustaju na nivo VB-a :( (daleko da oracle poredim sa vb-om :D ) ... u nekom trenutku ta jednostavnost jeste jeftinija.... naravno kosta uvek sa neke druge strane




samo ako ispis radis iz pl/sql-a ... ako ispis radis iz nekog programskog jezika (c/c++/java/php/...) sve se svodi na jedan printf sa par parametara ... opet, ovaj deo foruma je vezan direkt za mysql (svi ostali su zajedno tamo u onom drugom odeljku) ... dal zato sto je mysql "cudan", "drugaciji" ili zato sto su mysql korisnici smarali sa glupim pitanjima pa ste ih izbacili iz glavne price ne znam, ali ovaj "odeljak" je "mysql only" (aj da kazem +drizzle) tako da posto doticni nema pl/sql (niti bilo sta slicno) ....

@bogdan:

Ja sam radio na mnogo aplikacija, a ako bih napravio otprilike neku statistiku, polja u bazi su bar 80% tipa varchar.
Pogledaj i real world example, npr. Osoba ima atribute kao što su:
Ime i Prezime,
JMBG,
DatumRodjenja,
Adresa,
Grad,
Telefon,
Email,
itd...

Uglavnom radim sa MS SQL, nisam radio sa MySql ali svejedno...
Ako taj MySql DBMS ne tretira varchar tip (koji je se bukvalno najvise koristi) kao "First Class Citizen" i ima ozbiljan "performance impact", onda je MySql == SKRNDELJ.

Ako mislite da ce da ce jedno INT polje za JMBG da spasi performanse pored 16 drugih varchar polja onda mislim da debelo gresite.
Moje misljenje je da INT JMBG polje samo moze da zakomplikuje i da bez ikakve realne potrebe ogranici atribut koji, po svojoj formi koju je zamislila "trenutna administracija",
moze da preraste u nesto drugo sto se ne moze zapisati samo ciframa.

Razlika je u tome sto MySQL VARCHAR() tretira IDENTICNO kao sto ga tretira MSSQL (posto znam kako ga tretira SYBASE a MSSQL je preimenovani SYBASE sa fancy sminkom) i vrlo verovatno ga ORACLE tretira na isti nacin; a cak i to "identicno" sa MySQL-om radi BRZE nego i ORACLE i MSSQL u klasi baza od par hiljada slogova o kojima pricate...

Ono sto je drugacije je sto MySQL tretira CHAR() "drugacije" nego ga tretira MSSQL/ORACLE i ekipa te ako se u tabeli ne koriste varijabilne kolone tabela ima benefit brzine (koji u slucaju MSSQL-a ti nemas, a ja ne kazem da je MSSQL SKRNDELJ zato sto ne ume da iskoristi cinjenicu da je sirina tabele staticna) te samo kazem da ako MOZES da iskoristis cinjenicu da je CHAR() bolji od VARCHAR na tojh strani a znas da ce ti 99.9% slogova imati TACNO TU DUZINU koristenje VARCHAR je cista glupost. Da smo pricali o MSSQL-u nikad ne bi rekao da se koristi CHAR umesto VARCHAR posto je MSSQL jednako spor u oba slucaja... bas iz razloga sto smatraju da ce u 90% slucajeva da se koristi varchar pa se nisu trudili da ubacuju dodatnu optimizaciju za onih 10% slucajeva .. kao sto sam vec spomenuo, mysql od prvog dana (a zato danas imamo web na ovom stepenu razvoja na kom je ) radi u toj nisi od 10% gde mnoge stvari "nisu bitne" (stabilnost, sigurnost, durability, auditing etc etc etc) ... neke od tih "nebitnih" stvari su polako implementirane, neke su "ugurane", neke su "zamazane" ... ali je od prvog dana postavljeno da je upravljanje resursima i brzina #1 i da ima presedan u odnosu na sve ostalo... sada se to polako menja, potrebe trzista su drugacije, serveri su postali mnogo brzi, imaju mnogo procesora, cudo i karate rama .. dosli su ssd diskovi ... tako da i MySQL menja polako prioritete

Dakle nije poenta da MySQL nesto radi losije i da nesto nema, nego je poenta da MySQL (za razliku od vecine drugih) moze da iskoristi neku optimizaciju te je glupo istu ne iskoristiti.... Nemoj me pogresno razumeti, nema MySQL mnogo stvari gde moze da se pohvali da nesto radi bolje od oracle-a ili mssql-a (no videcemo za koju godinu, kako je novi gazda krenuo mislim da ce mssql uskoro biti kompletno pregazen - no videcemo) .. ali ovo jeste jedna od njih...

Mislim da dusans debelo gresi. Jedan INT i te kako moe da utice na performanse. Dokumentacija mysql o tipovima podataka i indeksima lepo opisuje i CHAR u odnosu na VARCHAR, a imamo i Bogdana ovde koji odlicno poznaje arhitekturu.

Radio sam i ja sa MSSQL bazama, ali nikada nisu bile previse zahtevne po pitanju performansi, uglavnom su sluzile za storidz velikog broja podataka.
Kada kreiramo veb aplikacije, onda ocekujemo veliku posetu. U tom slucaju je veoma bitno resiti indekse na pravi nacin, po meni je to bitnije u odnosu na to da li cete imati manje join ili vise prostijih upita. A za pravilne indekse je veoma bitna struktura podataka. Bogdan je pisao o viseslojnosti podataka, obavezno procitajte to...

Jedan int mozda nece da ustedi mnogo na velicini baze, ali ukoliko vam to postane princip i te kako ce znaciti.

ono sto se provlaci kroz celu temu i cime se opravdava tih 13 bajtova (ili u slucaju utf8 39 bajtoba) umesto 8 bajtova za int je
1. orakljivi kukaju sto moraju da pretvore NUMBER u STRING da bi ga prikazali i pravi im problem vodeca nula

bilo ko ko radi u nekom visem programskopm jeziku a ne pise aplikaciju kao u proslom veku u pl/sql-u taj problem nema tako da stvarno ne mogu da komentarisem taj deo

2. ostali kukaju kako su im "onda" i "tada" a i kod "onog projekta" i "tamo" i "tamo" gazde promenile zahtev 10 dana pred pustanje aplikacije public a onda su 3 dana posto je aplikacija pustena odlucili da slike nece vise da budu na disku nego u bazi i rekle da su oni ocekivali da baza podrzava i kineske karaktere posto "sta ako zaposle kineza" te im se obilo o glavu

ovo smo SVI prosli mnogo puta ... to je tuzna istina i prosta cinjenica u nasem poslu ... zahtevi se menjaju, poslodavci, klijenti i ostali "Zaduzeni" uglavnom nemaju pojma sta oce i menjaju to sta oce kako im dodje ... ali da bi im ispunili sve zahteve jedini nacin je da zaboravimo na relacione baze podataka i cuvamo sve podatke kao jedan BLOB ... ima i to smisla na mnogo mesta .. ali ovo nije mesto za pricu o tome ... ima *mnogo* razloga da se denormalizuje baza, ali da bi pravilno denormalizovao bazu moras prvo da budes svestan kako tacno izgleda njena normalna forma i da znas tacno sta si denormalizovao i zasto, sta si time dobio a sta izgubio ... ja sam na primer imao prilike da intervjuisem za razne poslove preko 2000 ljudi do danas .. (godinama je to bio deo "consulting paketa") ... 80% "database admin/devel" ljudi ne zna ni sta je bulova algebra a ne da ume da normalizuje neki izraz... u stvari, da se preciznije izrazim, 80% ljudi koji se predstavljaju database admin/dev expertima to ne zna .. (o drugim rupama u njihovom znanju necu ni da pricam), preko 50% njih misli da se database model pravi "odokativno - po osecaju" a skoro svi su ubedjeni da mogu da odrade savrsen db model "po osecaju" ....

dakle, ja sam rekao da je ovde bigint pravilan tip podataka i da ima slucajeva kada moze da bude 2 inta .. ima razloga da se koristi i CHAR() (retko ali moze) a varchar() je pogresno. To sve vazi iskljucivo za mysql. Za mongoDB ti je taaaaaaaako svejedno sta ce da bude tu .. ako ce aplikacija da bude pl/sql onda ti je sudjen varchar a ako ces da klikas u mssql-u onda sta ti je lakse da spojis sa svojim VB-om ili sta bolje access podrzava ..

a varijanta "sta ako sutra gazda kaze da u JMBG polje mora da upisem kineski karakter zato sto ...." to je van domena ove teme posto onda stavi lepo blob pa ces pokriti i ako gazda sutra trazi da mu png bude primarni kljuc za svakog zaposlenog ..

cuj moze :D ... koliko bih samo primera mogao da navedem gde je mala redefinicija par tabela ( par alter table komandi ) skinula server sa loada koji je isao na 40-50 i zabadao server kompletno na server koji je imao load ispod 4 i radio zastrasujuce dobro ... sve isto, ista aplikacija, isti podaci .. bez promene aplikacije ... mislim da sam samo ja odradio zadnje 3 godine jedno 50tak takvih .. da ne spominjem ceo tim u mysql koliko je takvih imao ... a o "malo smo redizajnirali bazu i malo smo promenili kod" promena gde je load isao i po 100 puta dole .. o tome necu ni da pricam ... (mislim da dosta ljudi ovde zna pricu o tehnickom direktoru jedne engleske firme koji je bio i glavni php+mysql developer i koji je imao platu od nekih 200KGBP brutto - nemam pojma koliko to izadje netto, recimo pola, koji se zbunio kada sam mu sa jednim alterom ubrzao upit sa oko 400minuta na ispod 3 sekunde :D ... posle objasnjenja sta sam uradio covek me pitao "what are indexes I don't understand what you just said, don't every table work like flat file?!" ... alo qme .. 200000 engleskih j*****h funti godisnje .. pa nek je porez pola ko u srbiji pa to je opet preko 8000 funti mesecno kesha ... database developer !!! ok nisu svi takvi, niti svi uspeju da se uvale u takvu oparenu firmu pa da imaju tolike plate ... ali .. daj ... pritom, posao pre ovog mu je bio u panduraciji, bio je glavni db developer za londonsku panduraciju ... no comment)

bitno je "naviknuti se" i "znati sta je optimum" ... ako ti ZNAS sta je OPTIMUM onda ti imas pravo da sebi dozvolis da ne uradis nesto optimalno zbog neceg drugog (jeftinije mi je da nabacam database model za sat vremena i nacukam app za 3 cuke posto ce imati 2000 slogova i ne mogu da ga naplatim ni 100 nemaca, nego da sada 2 dana pravim model, gubim 10 dana na programiranje kad na 2000 slogova to svejedno radi brzi i da ga cuvam u xml-u a nikako nema teorije da opravdam desed dana posla sa 100 nemaca) .... ali kada iz taka bez razmisljanja ides sa "varchar mi je najsigurniji" sutra kada bude prilika da imas posao sa 100M slogova u tabeli ti ces opet "odraditi" to sa varchar i savetovati klijenta da uzme "jaci server" i plati "dodatne licence" ovome i onome a onda ce naici neko ko ZNA i ti ces u naboljem slucaju izgubiti ugled, a vrlo cesto i posao.... nije se jednom desilo ....

@agvozden:

Ne može se porediti baza za neku Web prezentaciju sa nekom bazom za poslovnu upotrebu. Prosto je smešno mala količina podataka za Web u odnosu na bazu koja je pravljena za podršku poslovanju jedne, na primer, veleprodaje. Mnogo računanja, čuvanje integriteta podataka, podrška odlučivanju, i ... Tako da nema smisla porediti baze namenjene potpuno različitim namenama.



Do sada sam mislio da uskladištene procedure pomažu boljem održavanju baze. Pomažu da se ne mora voditi računa raznim verzijama aplikacije instalirana kod klijenta. Mislio sam da centralizuju i poboljšavaju održavanje baze. Mislio sam da baze nisu samo puko skladište podataka.

Ali, prevario sam se. Shvatio sam da to i nije baš tako. Shvatio sam da je veoma bitno da se uštedi koji kilobajt pa i koji megabajt bez obzira na veličinu današnjih diskova. Shvatio sam da je glupo koristiti blagodeti SQL-a za bilo šta osim za prikaz podataka jer je taj način programiranja veoma zastareo.

Ne znam samo šta će MySql-u uskladištene procedure, zašto pokušava nešto sa Inodb-om. Šta će im sve to? To zastarelo. Bacimo to i zaboravimo.

Ili da se malo zapitamo zašto je to sve implementirano.

u 50% slucajeva da, u 50% slucajeva prave mnogo veci problem nego sto je pomoc. Mozda sam ja staromodan ali biznis logika po meni treba da sedi u aplikaciji koja treba da ima vise slojeva, biznis logika ne treba da sedi u bazi podataka. Sve sto baza podataka treba da odradjuje (pored cuvanja podataka) je odrzavanje referencijalnog integriteta a tu stored procedure ne sluze nicemu.



vidis, to je recimo primer gde je biznis logika na bazi a ne na sloju aplikacije, po meni vrlo pogresan dizajn .. no nema bas nikakve veze sa temom



lako je biti sarkastican .. kao sto rekoh, sto se mene tice stavi sve u blob, potpuno odgovara tvojoj filozofiji .. ja cu uvek ako resenje moze da se napravi bolje, predloziti to bolje resenje ... a ti uvek mozes da koristis opstije resenje koje nece ustetedi taj megabajt .... velicina diskova je nebitna, diskovi su mnogo skup medij, sve i sa 15000RPM diskovima seek je za 10-20 redova velicine veci nego prema ram-u... cak i SSD diskovi se zagusuju sa IO-om a ni mssql ni oracle jos uvek ne umeju da koriste SSD diskove kako treba... eventualno oracle moze da ih iskoristi tako sto se potera na solarisu sa zfs-om koji radi layer 2 cache na ssd-u pa sam solaris radi kesiranje najcesce pristupanim podacima na ssd-u ... a ram je i dalje skup .. 64G i 128G masine jesu danas vrlo ceste cak i 256G masine nisu tako retke ali pogledaj koliko kosta jedna takva masina mesecno a onda pogledaj tu bazu podataka o kojoj pricas ... 256G je vec malo za veliki broj web aplikacija, o poslovnim aplikacijama necu ni da pricam .. za njih je to smesan procenat podataka sa kojima operisu tako da DA SVAKI MEGABAJT JE BITAN i dokle god vikend kursevi budu proizvodili "visual developere" kojima je svejedno dal aplikacija uzima 100 ili 1000M za rad (a moze 2M) i baze se budu ucile kroz access bice i komentara kako je memorija sada jeftina i kako su diskovi dzaba .... prvo ni jedno ni drugo nije tacno, drugo kolicina podataka sa kojima prosecna aplikacija operise raste mnogo brze nego sto padaju cene memorije i diskova i mnogo brze nego sto rastu brzine memorije i diskova tako da je i dalje za velike baze SVAKI BAJT BITAN .... e sad, ako ti operiras sa bazom od par stotina megabajta, razumem da te bas briga da potrosis dan duze da projektujes bazu kako treba posto ce ti xml odraditi posao za storage

Ma ne uzbuđuj se. To što sam napisao ne odnosi se na tebe. To je samo za druge da ne bufdu u zabludi. Ti ne odustaješ od svog xml-a. Nemam nameru da polemišem o tome šta je bolje. Zašto je MySql uveo procedure? Što te nisu poslušali i bacili ih na đubrište istorije? Samo tako nastavi i daleko ćeš dogurati. Možda te i zaposle kao ševa iz tvoje priče

zato sto postoji veliki broj korisnih primena za iste. Isto kao sto postoji i veliki broj primena za BLOB sto ne znaci da treba da u njega turamo JMBG vrednost "zato sto moze"



meni je u oraklu prilicno dobro... ne znam ko bi to trebao da me zaposli a ni odakle ta negativna energija ... ako ne verujes da ce ovo brze da radi na mysql-u od onoga i od istog toga na mssql-u ili oraklu, a ti probaj... teoretisanje o tome "sta je bitno u generalnom slucaju" je glupost ... cist primer je drugi post o IP adresama gde je ja mislim bolje odma implementirati IPV6 a ne limitirati se na IPV4 iako ce u startu 99% adresa (ako ne i 100%) biti IPV4 .. u ovom slucaju sa JMBG mislim da je gubljenje dodatnih bajtova cista glupost i da su svi izgovori na tu temu pogresni ...

@mkaras Nisam baš shvatio, pa, nije svaka baza za veb mala? Jedina razlika je u tome što na vebu, ili javnim servisima (SMS glasanja i slično) možeš očekivati veći broj zahteva u jedinici vremena u odnosu na desktop ili aplikacije kojima pristupa manji broj korisnika.
Ne znam šta je tu smešno ;)

I jedne i druge mogu imati različite tipove periodičnog izveštavanja i preračuna. Doduše, nikada nisam radio aplikaciju na vebu koja par dana vrti neke proračune, ali u svakom slučaju, vraćam se na indekse i tvrdim da je prava umetnost rešiti pravilno indeksiranje, a da je određivanje tipa podataka mnogo lakši posao.

nego, odmakosmo se od teme...

Ja i dalje tvrdim da bez uvida u zahteve aplikacije nema mnogo smisla davati decidirane odgovre da je nešto sigurno lošije ili bolje. Evo recite mi, koji tip kolone koristiti kada se čuva telefonski broj u bazi?

Ja ti Bogdane, apsolutno verujem da će int ili char uvek raditi daleko brže nego varchar. A da li je to bolje rešenje, zavisi od zahteva aplikacije. U većini aplikacija sa kojima sam radio razliku koju to pravi je neprimetna. A opet, ako očekujem da će mi korićenje optimalnijeg rešenja sa stanovišta performansi, kasnije napraviti druge probleme, ja bih (u slučaju da znam da neću imati problem sa performasama jer je zahtev aplikacije takav) svesno žrtvovao performase. Ako mi je aplikacija takva da su mu performanse bitnije, onda bih žrtvovao fleksibilnost. U ovoj konkretnoj diskusiji to znači da čuvanje JMBG kao dva int polja može da bude optimalno rešenje za jednu vrstu aplikacija, ali za većinu drugih je nepotrebno komplikovanje.

Kao nekog ko se razume kako mysql radi ispod haube, ja verujem da te uvek "zaboli" kada neko ne koristi prednost nečega što ste implementirali, ali nisu sve aplikacije takve da im je potreban svaki promil performansi ako zbog toga kasnije treba trošiti više vremena.

Da citiram rečenicu koju ste svi sigurno čuli:







Ja sam dosta razmišljao o tome ali sam na kraju sam se odlučio da za sada podržim samo IPv4, mada sam stavio da mi je ta kolona bigint umesto int da bi kasnije mogao da dodam još jednu bigint kolonu i podržim IPv6. Da radim projekat za sebe, verovatno bih odmah išao na ipv6, ali pošto je ovo projekat za klijenta koji za sada ne razmišlja o ipv6, neću ni ja!

pa bas u tome i jeste stvar. zahtev je JMBG, vrlo precizno definisana vrednost ... broj telefona je potpuno suprotan podatak, "opusteno definisan" ... ja u 90% slucajeva tu koristim varchar mada postoje razna resenja. Sav moj "decidirani stav" je baziran bas na tome da je JMBG vrlo definisana vrednost koja ce se u polju naci te nema nepoznanica... da je prica o "univerzalnom ID-u nekog coveka" odgovor bi bio drugaciji



da se ne ponavljam sad ... ono sa 2 int-a je bio primer kako je "to negde bilo korisno", ne kao savet da se tako radi, bigint je pravilan nacin, char() je ok nacin, varchar je pogresan nacin - za mysql, za mssql/oracle potpuno je svejedno da li varchar ili char, number je bolji ali zavisno od toga da li trosis pl/sql ili ne mozda ti je jeftinije da koristis char i bacis par bajtova po id-u (posebno ako ne koristis jmbg kao index). Kako je topic vezan za jmbg na mysql-u sta je bolje / isto na mssql/oracle/pgsql i ekipi nije preterano bitno



iskreno, ne boli me :D ... vikend je a boli me glava da radim nesto "pametno" pa eto imam vremena da pogledam sta je na forumu .. generalno koristim priliku da prenesem neko znanje, sta je bolje i zasto je bolje, bas za doticni mysql .. ako pogledas onaj "generalni sql forum" ne trudim se tamo da komentarisem bilo sta (iako znam i kako ostali sql serveri rade prilicno dobro i vidim dosta pogresnih saveta tamo) posto prosto - ima dovoljno ljudi sa dovoljno iskustva koji tamo mogu da podele svoje znanje ... obzirom na to da 80% mysql usera ne zna sve te korisne cinjenice o tome kako mysql radi, ja se potrudim da gde god je to moguce dodam neki koristan tip. To sto ce op verovatno da ima tabelu od 1000-2000 slogova i da verovatno nece koristiti JMBG za PK nego ce imati neki auto_increment a JMBG nece ni indexirati te je doticni obicni teret za disk (koji jeste dzaba) te stvarno moze da bude i u TEXT polju ... to je nebitno za samu temu... ako cemo da pricamo o "koji je najbolji tip podataka za JMBG - to je u mysql-u uvek BIGINT" a sad ne mora uvek da se koristi najbolje resenje ... no .. opet se ponavljam




za IP ja na primer svuda ostavljam u kodu mogucnost da to moze da bude V6 ali u bazi drzim INT sa varijantom "napravicu alter table kada bude bilo potrebno" zato sto znam da ce zahtev "jednom doci" ... gledam mnogo koda kod mnogih klijenata, svi podrzavaju V6, niko ga ne koristi ... kad pitam zasto kazu "ako ne stavis na app da podrzava ipv6 mnogo je teze prodajes" .. ja se u taj deo vec ne razumem al .. ima smisla

uporno pominjes perforanse sto potpuno razumem sa tvoje strane nekoga ko radi database internals ...
ali ovde si cini mi se malo kontradiktoran . Sta je brze : upit baz ikakve logike ali u nekoj stored -proc ili upit koji u string-u dolazi iz aplikacije .
Tu se performanse ne racunaju a za varchar se racuna ??


znaci krpi se baza alterima kada dodje neki zahtev a kako ce taj alter da se propagira na slojeve gore iznad
ostavices naravno da lupaju glavu VB kliktachi :)

Neces verovati iz sopstvenog iskustva na slozenijim bazama i aplikacijama kakvih sve izmena je bilo
zbog dodavanja jednog jedinog polja u bazi ili izmena istog... pogotovu ako imas razudjen nivo aplikacije koji koriste bazu (web ,desktop, itd..)
izvestaji kojekakvi itd .....
tako da uz svo duzno postovanje pricas kao neko ko ima veoma malo iskustva na aplikativnom nivou .



_{[Ovu poruku je menjao deerbeer dana 17.04.2011. u 21:52 GMT+1]}

@bogdan.kecman
Nemoj da se palis! Hteo sam jos pre neki dan da pisem ali mislio sam da je svima jasno kakva je razlika ako ti znas da ti se podatak nalazi npr. na milionitom bajtu ili ako moras da
prodjes milion bajtova da bi nasao podatak, tj mesto gde se nalazi podatak da bi ga procitao... :epo si formulom objasnio i ako nekome nije jasno onda ces se samo
upljuvati objasnjavajuci.



Bilo bi lepo kada kazes "podaci na Web-u" da kazes konkretno na koji sajt mislis i ja cu ti odmah postaviti link ka nekom drugom sajtu da ti pokazem koliko gresis. Odmaj da i da ti kazem
da recimo moj odgovor na sve moze da bude google i yahoo, ali naci cu ti i neke lokalne sajtove ako treba.

Na internetu ima milijardu sajtova i onda neko kaze da neka poslovna aplikacija ima vise racunjanja, cuvanja intefriteta podataka, podrska odlucivanju... vise od nekog web sajta.
Da li to znaci da si ti milijardu sajtova sve stavio pod isto, pod rang nekog bloga ili foruma?

Da li tebi recimo google adsense baza izgleda malo zahtevna i da nema puno racunanja i da je kolicina podataka smesno mala? I tamo imas fakture, ulaz i izlaz i kolicinu.
Tu je u pitanju novac i ne verujem da google samo pamti koliko je ko puta kliknuto i vrednost klika i da to daje sumirano svakom korisniku pojedinacno a da on (google) nema
detalje podatke za ceo svet i da nema jos hiljadu drugih informacija kako bi sprecio malverzacije koje su moguce i lako izvodljive. Pa da, a kolicina podataka je veoma mala tako da je sve strpano u jednu bazu.

@vladasu ... meni zanimljivo ... lecim blagu glavobolju cukajuci po prilicno besmislenom topicu :D opustencija

@deerbeer ... ja sam rekao da postoji 50% slucajeva kada su stored procedure korisne (na primer u kombinaciji sa trigerima za odrzavanje tabela sa medjurezultatima) ali kakve to veze ima sa JMBG-om .. u kojoj kombinaciji vidis stored proceduru sa JMBG vrednosti ?! osim eventualno da radis verifikaciju istog polja a tu ti je tek jednostavnije da je polje tipa BIGINT nego VARCHAR

sto se tog altera tice, da si procitao ceo post razumeo bi, ovako, nema svrhe .. ja rekoh da kod unapred UME da procesira V6 a baza je spremna samo je alter tu ako treba da se podigne sa 4 na 8 bajtova tako da nece da opterecuje sistem unapred dok ne bude neophodno. a za iskustvno, necu komentarisati :D ... prilicno je smesno ...

OK, slažem se ako je JMBG uvek samo JMBG. Poenta moje priče je da mi se isuviše često dešavalo da ovo na kraju ne bude tako.

A što se tiče broja telefona, i ja ga uglavnom stavljam u varchar baš iz razloga koje si objasnio. Ali eto baš sam radio jednu aplikaciju koja je radila kao SMS Gateway ("who called me" servis rađen za jednog od naših mobilnih operatera) gde bi mi svako drugi način čuvanja broja telefona osim kao bigint značio veliki gubitak performnansi, a zahtev aplikacije je bio takav da su performanse bile najbitnije. Međutim, ja sam u tom slučaju znao da broj telefona uvek dobijam u istom formatu jer ga sam ga dobijao od druge aplikacije pa samim tim nisam morao da brinem o tome šta ako stigne nešto što nije broj, a što je realno očekivati u gotovo svakoj drugoj aplikaciji gde čovek unosi broj.

Ček, zar ne treba za IPv6 16 bajtova (128 bitova)? Ja planiram da ga čuvam kao dva biginta, jel postoji neki bolji način? Hm, odosmo u offtopic...

odosmo u offtopic sa ipv6 jeste 128 bita ali malo drugacije, jedno je network prefix i drugo je host ip (host ip moze da bude mak adresa interface-a ili 64bitni crc ssh kljuca) ... ovo sto sam ja radio nije imalo potrebu za celom adresom (host ip mi je dovoljan posto je "skoro pa unique" - tj obezbedjuje slicnu kolicinu jedinstvenosti kao uuid ) ali odosmo daleko od teme a i u stvari nije bas dobar primer (moja greska sto sam ga uopste uveo)

Nemojte da offtopicujete.

Ova tema je offtopic jos od kraja prve strane

Pozzz

Mozda bude od koristi članak o JMBG sa Kotnikovog bloga:

http://nultibitovi.net/blog/jedinstveni-mati-ni-broj-gra-anina