[MySQL] Jaki typ pola dla rabatu Opcje

[SmokAnalog]

Cześć,

chcę stworzyć w bazie danych tabelę z rabatami (w procentach) dla poszczególnych użytkowników. Zastanawiam się jakiego typu pola najlepiej użyć. Pomysły:

1. float
   Zapisywać rabat w skali [0, 1]
2. decimal
   Tu też w skali [0, 1]
3. tinyint
   A tutaj w skali [0, 100]

Dwa pierwsze pomysły są bardzo podobne, ale zastanawia mnie czy użycie float jest w pełni bezpieczne dla dokładności obliczeń, bo jak wiemy z tymi zmiennoprzecinkowymi wartościami różnie bywa. Czy to ma jednak jakiekolwiek znaczenie dla wyniku o tak małej dokładności, jaką jest kwota pieniężna (zaledwie 2 znaki po przecinku)? Drugi pomysł, czyli decimal, to bardziej pewny format - zawsze go używam do zapisywania kwot pieniężnych. Trzeci pomysł to już inna bajka, ale kusi mnie "pewność" takich danych. Liczba całkowita to jednak liczba całkowita, a i dane czytelniejsze i zajmują mniej (1 bajt). Wadą jest to, że trzeba dołożyć operację dzielenia w każdym zapytaniu, co jest trochę upierdliwe. W praktyce pewnie i tak to napiszę obiektowo, więc to nie będzie wielki problem, no ale podebatować można

Jak Wy to widzicie?

[nospor]

Uzywaj pelnych liczb. Z tymi zmienno przecinkowymi zawsze ni z gruszki ni z pietruszki wyskakują glupoty.

[kayman]

rozwiązanie 3 jest najczytelniejsze i najmniej kłopotliwe na moje, matematyka w zapytaniu do bazy to naprawdę niewielki problem

btw. jak chcesz zrobić 1 lub 2 też musisz w jakiś tam sposób przygotować dane więc tak naprawdę stawiałbym na czytelność danych w bazie

[Pyton_000]

3, łatwiej później tym operować

[SmokAnalog]

@nospor
Z decimalem chyba głupoty nie wyskakują, bo on jest zupełnie inaczej przetwarzany niż floaty.

@kayman
Czytelność danych w bazie mnie nie interesuje, nie będę czytał sobie bazy przed snem Matematyka jest upierdliwa o tyle, że jak będę liczył w stu miejscach cenę, to będę musiał wszędzie dodawać ten dzielnik. Chociaż tak jak mówiłem, najprawdopodobniej zrobię metodę do obliczania cen, która będzie wykonywała dodatkowe mnożenie przez rabat jako dodatkowe zapytanie. Nie odważę się dodawać rabatu do każdego zapytania osobno (bo wydajność, ble ble), bo zbyt łatwo o tym zapomnieć.

@pyton
Dlaczego łatwiej operować tinyintem niż decimalem w tym przypadku?

Rozwijam dyskusję, chociaż wbrew pozorom nie mam ciśnienia na decimal. Na tym etapie mogę jedynie powiedzieć, że float przegrywa z kretesem

[nospor]

Z decimalem chyba głupoty nie wyskakują, bo on jest zupełnie inaczej przetwarzany niż floaty.

Chodzi o liczby rzeczywiste. Niewazne czy decimal czy nie i tak predzej czy poźniej będą z tym kłopoty. Jesli wiec masz mozliwosc, a masz, to jedź na pełnych liczbach a unikniesz zbednych klopotow i przerobek

[Pyton_000]

Łatwiej bo to int, możesz sobie wyświetlać gdzie chcesz w postaci całkowitej wartości %.
A doliczenie rabatu w jednym miejscu to nie problem. poza tym mały zakres, miało pamięci.

Od decimal przy obliczeniu będzie tylko się różnił że do obliczenia int / 100 i nic więcej. reszta zostaje bez zmian w obu przypadkach.

[kayman]

Czytelność danych w bazie mnie nie interesuje, nie będę czytał sobie bazy przed snem

zmienisz zdanie jak wyjdą głupoty w czasie testów, var_dumpów czy za rok będziesz miał do dopisania coś tam