[ Orome @ 08.02.2017. 11:15 ] @
Ovako, imam kolonu varchar 7. u njoj je 5 brojeva. kada u SQL Yog-u napisem upit u kom kažem WHERE kolona='12345' nema pogotka. Kada promenim u WHERE kolona=12345 rezultat bude uredan. Ono što sam zapazio je to da bez navodnika radi nešto kao Full Text Search i zato ga i pronađe. Kada napišem WHERE kolona LIKE '%12345%' rezultat bude uredan. Ono što je još čudnije je to da funkcija LENGTH nad tom kolonom vraća 7, kao da ima 7 karaktera, isto vraća i funkcija CHAR_LENGTH. Ono što moram napomenuti je to da su podaci upumpani iz nekog Excela. Takođe u interfejsu mi prikazuje dva kvadratića na kraju kolone. rešio sam problem tako što sam uradio update kolone sa LEFT(kolona,5) tj tako što sam je apdejtovao sa prvih 5 karaktera iz nje same. bez obzira interesuje me kako sam mogao detektovati ovaj problem da nije cela kolona petocifrena. čak ga ovim nisam ni identifikovao nego samo zakrpio. kako sam upitom mogao izdvojiti problematične.
[ bogdan.kecman @ 08.02.2017. 11:28 ] @
ako je kolona varchar i ti uradis
WHERE kolona='12345'
on radi string match .. pitanje sta je tacno u "kolona" ako je recimo ' 12345' to nije isto sto i '12345' i zato nemas match
ako radis WHERE kolona=12345 on onda radi implicit konverziju kolona u int a ' 12345' i '12345' i '12345 ' se u int konvertuju kao 12345 pa imas match

Citat:

je još čudnije je to da funkcija LENGTH nad tom kolonom vraća 7, kao da ima 7 karaktera, isto vraća i funkcija CHAR_LENGTH


zato sto je u polju ' 12345' ili '12345 ' ili tako nesto i zato ti i kaze 7

pitanje je zasto cuvas brojeve u varchar polju

Citat:
interesuje me kako sam mogao detektovati ovaj problem da nije cela kolona petocifrena.


trebao si da broj cuvas kao broj a ne kao string i tako ne bi imao problem

Citat:
čak ga ovim nisam ni identifikovao nego samo zakrpio. kako sam upitom mogao izdvojiti problematične.


Code:
select * from t1 where CAST(CAST(kolona AS INT) AS CHAR(7)) != kolona;



[ Orome @ 08.02.2017. 13:12 ] @
Hvala na odgovoru bogdane.
Ne mogu da čuvam kao INT jer nije obavezno da će biti broj, iako u ovoj bazi jeste. Nemam space ni ispred ni iza petocifrenog broja, zato i jeste čudno što LENGTH vraća 7. znam da je ' 12345' različito od '12345' i od '12345 '. Čvrsto verujem da nije neki propust u pitanju. Ispisuje mi dva kvadratića nakon broja u aplikaciji što po meni možda ukazuje da je povukao neku informaciju iz Excela koju SQL Yog ne može interpretirati i zato u bazi stoji u koloni samo broj bez ijednog space. po netu sam čitao da može biti binarna informacija koju je mogao povući iz Excela iz kolone koja nije bila dobro formatirana ali mi i to ne zvuči verovatno. Collation mi je cp1250 general ci. Još nešto, kada promenim petocifren broj u jedan space u toj koloni i snimim, a zatim ja ručno iskucam taj petocifren broj nakon toga radi pretraga kako treba. imam osećaj da je u pozadini nešto što pravi problem. innodb engine i verzija 5.5.22.
[ bogdan.kecman @ 08.02.2017. 13:24 ] @
Citat:
Nemam space


imas nesto! uradi select hex(polje) pa vidi sta ti se nalazi tu .. nesto
ocigledno imas

Citat:
Ispisuje mi dva kvadratića


pa vidis da imas nesto ..

nema to veze sa innodb-om i verzijom, upisao si neko smece u bazu, sa
hex() mozes videti koji su to tacno bajtovi, a kako su tu dospeli to
vidi sa tim ko je importovao i kako je importovao datu
[ djoka_l @ 08.02.2017. 13:33 ] @
Dobrodošao u svet ETL-a

Ja se više od dvadeset godina bavim problemima migracija i nagledao sam se svakavih gluposti sa raznim bazama. Počevši od toga da automatski alati za migraciju pretvore, na primer, Number polje iz Access baze u VARCHAR2(1) u Oracle bazi, preko gomila gluposti sa punjenjem đubreta na različite druge načine.
Ono što je generalna ideja vodilja kod svih ETL alata - koristi ih ako moraš, bolje je ako sam napišeš. AKo je ikako moguće, ne radi migraciju direktno u produkcionu bazu, uvek je bolje da imaš staging area gde možeš da napraviš različite testove, pronađeš probleme i iskoristiš SQL za dodatne transformacije i testove "zdravlja" podataka.

Ono što je poseban problem su CHAR podaci. Kod datuma i brojeva, problem se relativno brzo nalazi, u samom procesu loada podataka (baza neće pustiti da u nju uđe ono što je neispravan datumski ili numerički podatak). Problem je ako je podatak sintaksno ispravan, a nelogičan.

U CHAR ulazi svaka glupost. Jedino ograničenje je dužina stringa. Osnovno kod stringova je provera da li sadrže non-printing znakove da li su padovani sa leve ili desne strane blenkovima, da li postoji problem mapiranja sa jedne kodne stranice na drugu. Da li možda fajlovi sadrže BOM koji se ne vidi u tvom omiljenom editoru itd. Cela zabava sa CHARom...