JMBG - tip podataka

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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.

Potpis

Moj Veb Sajt HostCentar Blog
Aleksinac Južna Srbija TimeOut

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

@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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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

Potpis

Moj Veb Sajt HostCentar Blog
Aleksinac Južna Srbija TimeOut

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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 .

Potpis

Viva lollapalooza

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

Potpis

_{[Ovu poruku je menjao VladaSu dana 14.06.2003. u 11:22 GMT+1]}

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

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

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)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

Nemojte da offtopicujete.

Potpis

I don't need a girl for sex , All I Need is Binary and HEX

Ova tema je offtopic jos od kraja prve strane

Potpis

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić