kate87
2018-07-11 20:31

Pole w bazie o nazwie "number" typ char, przechowujące sekwencyjne liczby. Kate padła jak krowa rażona piorunem...

czysteskarpety

Kate jest w ekstazie, bo grzebie w bazie :]

kate87

@furious programming: nie wiem, chyba nie chcę tego wiedzieć, ale to jeden z licznych kwiatków w tej bazie. @czysteskarpety a żebyś wiedział :P @Pitrek1991 ja raczej płakałam, aczkolwiek taki mógłby być odgłos :)

Pitrek1991

ja pierwsze co, pacze w baze - wtedy przynajmniej zaczynasz wiedzieć, dlaczego wszystko inne się wysypuje...

kate87

@Pitrek1991: no i dlatego aplikacja działa jak działa, a spece się cieszą że "udało się napisać soft na miarę XXIw." tylko że ten soft wali backendowym kodem w odpowiedziach przy obsłużonej 500-ce, albo totalnie na twarz kiedy 500-ka jest nieobsłużona.

somekind

No i dobrze, przynajmniej wiadomo co debugować.

kate87

zwłaszcza na produkcji :D

loza_szydercow

Czym różni char od Inta choćby :] ?

konfident

@loza_szydercow: Czym różni się litera od liczby choćby :] ?

kate87

Tym samym co w językach programowania. Jesli zalezy Ci na liczbach całkowitych tak jak w tym przypadku i ważne jest aby to byly liczby tak jak w mojej bazie to nie powinno byc chara tylko np int z wskazaniem ze ma 0 miejsc dziesiętnych. Poza tym nazwanie kolumny typem danych. Nawet przy wykorzystaniu ORMa nie powinno sie to udać.

loza_szydercow

Na jakim poziomie? Bo na poziomie kodu będzie się różnić typem. Tylko tak się zastanawiam czy typy pól w bazach SQL (storage types) powinny mieć przełożenie 1:1 na typy używane w logice biznesowej.

kate87

No jak architekt jest debilem to bazodanowiec powinien za niego pomyśleć. Ogólnie wszyscy powinni myśleć. A baza wstępnie ma zaimplementowane pewne walidacje i może sypnąć bledem bazodanowym kiedy jakis pacjent próbuje wykonać cos niedozwolonego. Nie trzeba juz potem z poziomu aplikacji klepać kolejnego kodu tak na upartego. Poza tym mlody dzieki ORMowi dzisiaj robi zmiany typów pol w bazie bo się okazalo ze np typ double nigdy sie nie zrówna z wyszukiwanymi wartościami.

loza_szydercow

@kate87: No i to już coś konkretnego. Problem z typami w bazach danych jest taki sam jak z upychaniem w nich logiki (walidacje, procedury, triggery). One mogą się różnić w implementacji pomiędzy silnikami. Może ktoś użył tutaj char bo dawało mu to jakiś zysk wydajności, ewentualnie ten typ pola mógł mieć najmniejsze zróżnicowanie jeśli chodzi o implementacje dostawców. Np. tutaj https://asktom.oracle.com/pls[...]ESTION_ID:2048810500346778955 wychodzi na to że Oracle i tak traktuje (wewnętrznie) pola Number jako string - tyle że stałej długości (czyli nie przymierzając Char).

kate87

Ale to nie oracle i w chara możesz wpisać wszystkie znaki kodu ASCII a nam zalezy na tym aby byly to liczby i nigdy nie pojawił sie tam zaden znak inny niz cyfra. Poza tym sa to dokumenty księgowe wiec nie moze byc również w nich luk i przerw.

loza_szydercow

Ale ty tylko przesuwasz problem - bo chodzi o walidację. Problem jest zresztą trywialny bo konwersja CHAR na Number powinna być bezbolesna - jeśli dane są spójne. Bo jak nie są spójne to wcale nie znaczy że ktoś skrewił wybierając ten typ w bazie tylko że walidacja poziom wyżej jest do d**y i w sumie dzięki niemu to wyszło na jaw :]

kate87

No generalnie to kiepski architekt zapodal taki a nie inny typ danych wiedząc dokladnie do czego bedzie on używany. Typy danych powinny byc spójne, przynajmniej tak mnie zawsze uczyli. Poza tym z tego co widzę warstw zapisujacych do baz jest kilka. Ta baza jest jedna z najniższych. Jesli wyzej zapisze sie cos z zadka, to w tej bazie wyladuje cos czego byśmy nie chcieli.

loza_szydercow

Jak dla mnie spójność znaczy jedynie tyle że jeśli coś jest typu A to po drodze bez mojej wiedzy automagicznie nie stanie się B. Jeśli stanie się to za moją wiedzą to nie mam z tym problemu. Można dyskutować czy jest to właściwe gdy ze zmianą typu tracimy część informacji ale to pierdoły na inną dyskusję. Problem jest tylko taki że storage type ma bardzo luźny związek z charakterem danych który przechowuje. Zresztą predefiniowanych storage type jest niewiele - niektóre silniki dopuszczają możliwość definiowania swoich typów ale chyba mało kto się w to bawi bo to zabija przenośność takiej bazy. Więc czasem wybierasz jakiś storage type kierując się czymś innym niż intuicja np. taki który nie gubi informacji a może mieć jakiś inny benefit (np. wydajność) - np. varchar czy też char do składowania daty. Wszystko zależy ;)

tamtamtu

w jednej aplikacji mamy number jako nvarchary - importujemy dane z erp gdzie te numbery sa faktycznie intami/longami - ale jesli dalibysmy long to na pewno trafilby sie klient ktorego numery nie bylyb liczba :D

loza_szydercow

@tamtamtu: Jeśli mnie pamięć nie myli to Number chyba też nie ma zdefiniowanej sztywnej szerokości.

kate87

Niestety nie mogę miec pewności co jest po drodze. Zwłaszcza ze ta liczba pochodzi z urządzenia, a nie od człowieka. W dodatku z urządzenia w miejscu publicznym. Co prawda nie ma do niej niby dostępu dla osob postronnych oprócz osoby obslugujacej urzsdzenie. Ale urządzenie pod spodem ma androida i jest 24/7/365 podlaczone do Internetu a przeladarka nie jest w żaden sposób zablokowana.

loza_szydercow

W takim wypadku to narzekanie że jakieś pole w bazie danych definiuje się jako char to twój najmniejszy problem :]

yarel

Bywa, że po naprawienia bzdury człowiek mówi sobie jakiś czas później "acha, to dlatego tak było" :D

loza_szydercow

@yarel: I zazwyczaj bywa to poprzedzone jakimś większym fakapem na produkcji :D

Bartosz Wójcik

Baza danych zdyskryminowała twój prostolinijny tok myślenia? Już dzwonię do Szczuki :P

kate87

Dzwoń dzwon tylko Kazia rozumie równie zdyskryminowanych jak Ty.

Dregorio

Poprawcie mnie jeśli się mylę, ale np. w konstruktorze BigDecimal trzeba podać string, by 25.07 nie wyglądało jak 25.07000000000067 wiec pole char ma jhyba akiś sens? Czy gadam bzdury?

kate87

Ok male wyjasnienie skad w ogole wzial sie problem. Otoz mielismy przypadek iz trzeba bylo zrobic porownanie na wartosci pienieznej. No i junior zrobil to porownanie tylko wynikow jakos nie bylo, wiec zajrzelismy do bazy, w where wrzucilismy konkretna wartosc liczbowa ktora faktycznie w polu wystepowala. Ale select nie zwrocil zadnych wynikow. Wiec zaczelismy drazyc dlaczego, szybko okazalo sie ze typ pola to double. Typ double sklada sie z czesci dziesietnej "reprezentowanej" przez mantyse. Zatem nawet jesli podalo by sie wartosc wprost to ona nigdy sie noe zrowna z wartoscia w bazie. W tym przypadku akurat operujemy na dosc niskich kwotach wiec sila rzeczy typ pola byl zle dobrany.

kate87

Co do BigDecimal, w javie tak jest natomiast w innych jezykach nie wiem. Raczej staram sie eliminowac potrzebe konwertowania bez potrzeby jesli operuje na pieniadzach.

loza_szydercow

To tam w końcu był char czy jakiś double? Swoją drogą trzymanie kasy na liczbach zmiennoprzecinkowych - ktoś mógł stać się bogaty :D

kate87

@loza_szydercow: w tamtym przypadku byl char. Ale wykryty tykko i wylacznie przez to iz zaczelam zwracac uwage na to co sie dzieje w bazie. Potem to pokonwertowalismy, ale ile jeszcze miejsc w bazie jest gdzie wsadzone sa double? Miedzyczasie okazalo sie tez ze te double sa powiazane z Active Records bo ktos wymyslil sobie ze orm jest lekarstwem na wszystko. AR nie do konca nadaje sie do operacji na kasie. Do raportow tez sie nie nadaje a 3/4 apki to raporty. Zdrowy rozsadek gora.:)

somekind

AR to przede wszystkim w ogóle się z ORM nie komponuje.