Najlepszy typ danych do przechowywania wartości w MySQL

Możesz użyć DECIMAL LUB NUMERIC oba są takie same

Typy dziesiętne i liczbowe przechowują dokładne wartości liczbowe danych. Te typy są używane, gdy ważne jest zachowanie dokładnej precyzji, na przykład z danymi pieniężnymi. W MySQL NUMERIC jest zaimplementowany jako dziesiętny, więc poniższe uwagi dotyczące dziesiętnego odnoszą się jednakowo do liczbowego. : MySQL

tj. DECIMAL(10,2)

Dobra lektura

To zależy od twoich potrzeb.

Użycie DECIMAL(10,2) zazwyczaj wystarczy, ale jeśli potrzebujesz nieco dokładniejszych wartości, możesz ustawić DECIMAL(10,4).

Jeśli pracujesz z dużymi wartościami zamień 10 na 19.

Wolę użyć BIGINT i zapisać wartości przez pomnożyć przez 100, aby stała się liczbą całkowitą.

Na przykład, aby reprezentować wartość waluty 93.49, wartość należy zapisać jako 9349, wyświetlając wartość możemy podzielić przez 100 i wyświetlić. Zajmie to mniej miejsca.

Uwaga:
Przeważnie nie wykonujemy currency * currency mnożenia, w przypadku gdy to robimy to dzielimy wynik przez 100 i przechowujemy, tak aby wraca do właściwej precyzji.

Jeśli Twoja aplikacja musi obsługiwać wartości pieniędzy do biliona, to powinno działać: 13,2 Jeśli musisz przestrzegać GAAP (ogólnie przyjętych zasad rachunkowości), użyj: 13,4

Zazwyczaj należy zsumować wartości pieniędzy na 13,4 przed zaokrągleniem wyjścia do 13,2.

W rzeczy samej zależy to od preferencji programisty. Osobiście stosuję: numeric(15,4) w celu dostosowania się do ogólnie przyjętych zasad rachunkowości ( GAAP).

Spróbuj użyć

Decimal(19,4)

To zwykle działa z każdym innym DB, jak również

W tym czasie zadano to pytanie, nikt nie myślał o cenie bitcoina. W przypadku BTC prawdopodobnie nie wystarcza użycie DECIMAL(15,2). Jeśli Bitcoin wzrośnie do $ 100,000 lub więcej, będziemy potrzebować co najmniej DECIMAL(18,9) do obsługi kryptowalut w naszych aplikacjach.

DECIMAL(18,9) zajmuje 12 bajtów miejsca w MySQL ( 4 bajty na 9 cyfr ).

Używamy double.

*gasp *

Ponieważ może reprezentować dowolną 15-cyfrową liczbę bez ograniczeń co do miejsca dziesiętnego . Wszystko za nędzne 8 bajtów!

Więc może reprezentować:

• 0.123456789012345
• 123456789012345.0

...i wszystko pomiędzy.

Jest to przydatne, ponieważ mamy do czynienia z globalnymi walutami , A {[0] } może przechowywać różne liczby miejsc po przecinku, które będziemy prawdopodobne spotkanie.

Jeśli spróbujesz zrobić to samo z decimal, potrzebujesz decimal(30, 15), który kosztuje 14 bajtów.

Caveats

Oczywiście używanie double nie jest bez zastrzeżeń.

Jednak to nie jest utrata dokładności, jak niektórzy zwracają uwagę. Nawet jeśli double sama może nie być wewnętrznie dokładna do systemu bazowego 10, możemy zrobić to dokładnie przez zaokrąglenie wartości pobieramy z bazy danych do jej znaczących miejsc po przecinku. W razie potrzeby. (np. jeśli ma być wyprowadzony i wymagana jest reprezentacja bazy 10.)

Zastrzeżenia są takie, że za każdym razem, gdy wykonujemy arytmetykę z nim, musimy znormalizować wynik (zaokrąglając go do znaczących miejsc po przecinku) przed:

1. dokonując na nim porównań.
2. odpisuję to do baza danych.

Innym rodzajem zastrzeżenia jest to, w przeciwieństwie do decimal(m, d) gdzie baza danych uniemożliwia programom wstawianie liczby większej niż m cyfry, nie ma takich walidacji z double. Program może wstawić wprowadzoną przez użytkownika wartość 20 cyfr i skończy się to cichym zapisem jako niedokładna kwota.

Mnoży 10000 i przechowuje jako BIGINT, jak "waluta" w Visual Basic i Office. Zobacz https://msdn.microsoft.com/en-us/library/office/gg264338.aspx