Cześć,
jakiś czas temu oglądałem na YT pewne sugestie odnośnie przechowywania danych w bazie danych i ktoś sugerował, aby zmienne typu decimal przechowywać w postaci dwóch liczb całkowitych.
A moje pytanie jest takie czy spotkaliście się z czymś takim w praktyce a jeśli tak to jak się to według was sprawdza? Niby ma to jakiś sens i nawet zastanawiam się czy u siebie czegoś takiego nie zaimplementować, ale jednak trochę to dziwne rozwiązanie i mam duże wątpliwości czy to dobry kierunek...
0
4
A jaki problem miało by to rozwiązać? Może to dotyczyło jakiegoś konkretnego silnika baz danych i jakiejś konkretnej ułomności.
4
Jaka baza?
Dlaczego nie można użyć typu decimal (albo innego zmiennoprzecinkowego, który dana baza oferuje)?
Jakie są zalety takiego rozwiązania?
Masz może link do tego materiału na YT?
Moim zdaniem to nie ma sensu. Generalnie celowałbym w typ zmiennoprzecinkowy, bo raczej obecnie każda baza ma to w standardzie. A jeśli z jakiegoś powodu nie to już prędzej bym poszedł w stringa, a nie kombinował ze sklejaniem czy tam przeliczaniem wartości po stronie klienta. Jeśli ktoś argumentuje to tym, że daje to oszczędność miejsca to jest to trochę słaby argument - w bazie, w której masz pełno śmieci to w praktyce żadna oszczędność.
2
@Kofcio :
Niby ma to jakiś sens i nawet zastanawiam się czy u siebie czegoś takiego nie zaimplementować,
Tak konkretnie, to jaki sens w tym widzisz? Po co chcesz to u siebie implementować?
0
Chyba faktycznie macie rację, że to bez sensu...
Tego filmiku na YT nie znajdę (widziałem go dawno temu), ale chyba bardziej chodziło o wydajność a nie o miejsce (?). Ale właśnie też dokładnie nie pamiętam.
Temat do zamknięcia ;)
2
Jeśli nie wiadomo o co chodzi, to zapewne chodzi o $$$.
To jest jedna z metod przetrzymywania, złotówki w jednej kolumnie, grosze w drugiej.
Ja się z tym nie spotkałem, ale słyszałem
1
Productionserver napisał(a):
Jeśli nie wiadomo o co chodzi, to zapewne chodzi o $$$.
To jest jedna z metod przetrzymywania, złotówki w jednej kolumnie, grosze w drugiej.
Tak się zastanawiam jakie to ma zalety względem przechowywania wartości jako int w groszach, jak już nie chcemy pól stałoprzecinkowych? Zysk żaden, a moim zdaniem same minusy. Widziałem bazy gdzie wartości kwotowe były przechowywane jako grosze oraz jestem w stanie coś takiego zrozumieć. Jednak oddzielanie groszy od złotówek to już bezsens dla mnie. Ani to sensowne, ani wydajne. Nawet zwykły select w stylu:
select
sum(A.WARTOSC)
from
FAKTURY A
where
A.DATA <= '2024-01-01'
and A.DATA >= '2024-01-31'
Będzie bardziej karkołomny niż tutaj przedstawiony. Wiadomo napisanie analogicznego zapytania obsługującego dwa oddzielne pola to nie będzie jakaś fizyka kwantowa, ale pytanie po co utrudniać sobie życie? Przecież numeric(12,2) nie będzie znacząco wolniejszy od integer
1
Kofcio napisał(a):
Cześć,
jakiś czas temu oglądałem na YT pewne sugestie odnośnie przechowywania danych w bazie danych i ktoś sugerował, aby zmienne typu decimal przechowywać w postaci dwóch liczb całkowitych.
A moje pytanie jest takie czy spotkaliście się z czymś takim w praktyce a jeśli tak to jak się to według was sprawdza? Niby ma to jakiś sens i nawet zastanawiam się czy u siebie czegoś takiego nie zaimplementować, ale jednak trochę to dziwne rozwiązanie i mam duże wątpliwości czy to dobry kierunek...
Jedyna podobna rzecz, którą stosujemy, to reprezentowanie np. szansy na coś w postaci liczby z "precyją", np. liczba 0, to 0%, a 1 000 000 to 100.0000%, 2 543 21 to 24.54321, 1 to 0.000001%
2
Takie rzeczy robiło się, gdy baza, lub język aplikacji nie obsługiwał Decimali.
Taki c++ bez dodatkowych bibliotek nie ma Decimali, a jedynie floaty. A z floatami jest tak, że nie oferują wystarczającej precyzji podczas przechowywania oraz operacji na liczbach (końcówki potrafią się gubić), co w aplikacjach finansowych jest niedopuszczalne.
Podsumowując - dziś mamy typy o definiowanej precyzji i skali (Decimal, numeric, money, etc.), a dawniej trzeba było szyć.