[es] - JMBG - tip podataka

agvozden
Aleksandar Gvozden
founder
Info-G
Beograd

Član broj: 37813
Poruke: 1123
*.dynamic.isp.telekom.rs.

Sajt: www.gvozden.info

+68 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 09:44 - pre 158 meseci}

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

Moj Veb Sajt HostCentar Blog
Aleksinac Južna Srbija TimeOut

Odgovor na temu

Shadowed
Vojvodina

Član broj: 649
Poruke: 12848

+4784 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 09:55 - pre 158 meseci}

Citat:

deerbeer: Pojavi se "stranac" u aplikaciji sa svojim "jmbg-om" ili id-ijem koji osim brojeva sadrzi i karaktere :)

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

Nebojsa Milanovic: Što se tiče Trumpa, smatram ga vrhunskim predsednikom i voleo bih da živim u državi na čijem je on čelu.
Nebojsa Milanovic: Rusija ne laže, ne vodi osvajačke ratove
Nebojsa Milanovic: Trump je svetla tačka u USA blatu.

Odgovor na temu

dusans
Stojanov Dušan
Pančevo

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

+311 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 10:02 - pre 158 meseci}

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 ;)

Odgovor na temu

deerbeer
Beograd

Član broj: 174418
Poruke: 1189
*.dynamic.sbb.rs.

+395 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 10:03 - pre 158 meseci}

Citat:

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

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

Citat:

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

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]}

Viva lollapalooza

Odgovor na temu

VladaSu

Član broj: 31634
Poruke: 1099
*.dynamic.isp.telekom.rs.

+218 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 10:14 - pre 158 meseci}

Code (php):

str_pad('123456', 13, 0, STR_PAD_LEFT);

 

Code (csharp):

str.PadLeft(13, '0'));

 

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

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

Odgovor na temu

Milan M. Radovic
Web Developer
Pančevo

Član broj: 16959
Poruke: 743
82.117.198.*

+25 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 11:28 - pre 158 meseci}

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

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

Odgovor na temu

mozdasamjaamozdainisam

Član broj: 274672
Poruke: 341
*.static.chello.nl.

+191 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 15:50 - pre 158 meseci}

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

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: JMBG - tip podataka

^{14.04.2011. u 23:12 - pre 158 meseci}

milane, varchar NIKAD nije dobro resenje za ovaj problem

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

Odgovor na temu

Shinhan
PHP programmer
Subotica

Član broj: 12327
Poruke: 372
*.static.isp.telekom.rs.

Jabber: shinhan@elitesecurity.org
ICQ: 400847988

+4 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 07:18 - pre 158 meseci}

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

"Common sense is not so common." - Voltaire

Odgovor na temu

Miroslav Ćurčić
ex mVeliki
Novi Sad

Član broj: 19034
Poruke: 1118
*.adsl.eunet.rs.

+19 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 07:51 - pre 158 meseci}

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 (?!?)

_{"The quieter you become, the more you are able to hear."}
Blog | PowerCMS

Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3453

Jabber: djoka_l

+1462 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 10:08 - pre 158 meseci}

Citat:

bogdan.kecman: milane, varchar NIKAD nije dobro resenje za ovaj problem

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

Odgovor na temu

agvozden
Aleksandar Gvozden
founder
Info-G
Beograd

Član broj: 37813
Poruke: 1123
*.dynamic.isp.telekom.rs.

Sajt: www.gvozden.info

+68 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 10:30 - pre 158 meseci}

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

Moj Veb Sajt HostCentar Blog
Aleksinac Južna Srbija TimeOut

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 12:00 - pre 158 meseci}

Citat:

djoka_l: Nije mi jasan tako decidiran Bogdanov stav

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

Citat:

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

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

Citat:

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.

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

Citat:

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

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

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

Odgovor na temu

dejankr
Dejan Krsmanovic
JavaEE programer
Beograd

Član broj: 7842
Poruke: 384
*.static.sbb.rs.

+1 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 14:20 - pre 158 meseci}

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.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 14:37 - pre 158 meseci}

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

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

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 14:38 - pre 158 meseci}

Citat:

na optimizaciju na uštrb fleksibilnosti

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

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

Odgovor na temu

djoka_l
Beograd

Član broj: 56075
Poruke: 3453

Jabber: djoka_l

+1462 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 14:51 - pre 158 meseci}

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

Odgovor na temu

dejankr
Dejan Krsmanovic
JavaEE programer
Beograd

Član broj: 7842
Poruke: 384
*.static.sbb.rs.

+1 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 15:14 - pre 158 meseci}

Citat:

bogdan.kecman: 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 ..

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.

Odgovor na temu

bogdan.kecman
Bogdan Kecman
"specialist"
Oracle
srbistan

Član broj: 201406
Poruke: 15887
*.31.24.217.adsl2.beograd.com.

Sajt: mysql.rs

+2377 Profil

Re: JMBG - tip podataka

^{15.04.2011. u 15:17 - pre 158 meseci}

Citat:

djoka_l: Bogdane, ako je to problem sa performansama na MySql onda razumem tvoj stav, ja radim uglavnom na Oracle bazi.

Citat:

bogdan.kecman: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

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

Citat:

djoka_l:Nije mi jasna razlika između CHAR i VARCHAR2 tipa na MySql, na Oracle bazi CHAR je fiksne dužine

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

Citat:

djoka_l:na Oracle bazi ne postoji u bazi INTEGER tip nego je on izveden od NUMBER

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

Citat:

djoka_l: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).

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

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

Odgovor na temu