Який найкращий тип даних SQL для значень валюти? Я використовую MySQL, але віддаю перевагу незалежному типу даних.

Щось подібне Decimal(19,4)зазвичай працює досить добре в більшості випадків. Ви можете налаштувати масштаб та точність відповідно до потреб чисел, які потрібно зберігати. Навіть у SQL Server я, як правило, не використовую " money", оскільки це нестандартно.

Єдине, на що потрібно стежити - це якщо ви переходите з однієї бази даних до іншої, ви можете виявити, що DECIMAL (19,4) і DECIMAL (19,4) означають різні речі

( http://dev.mysql.com/doc/refman/5.1/uk/precision-math-decimal-changes.html )

    БАДА: 10,5 (10 цілих чисел, 5 знаків після коми)
    MYSQL: 15,5 (15 цифр, 10 цілих (15-5), 5 десяткових)

Також важливо розробити, скільки десяткових знаків може знадобитися для ваших розрахунків.

Я працював над заявкою на ціну акцій, яка вимагала розрахунку ціни на мільйон акцій. Пропоновану ціну акцій потрібно було зберігати до 7 цифр точності.

Відповідь Ассафа о

Залежить від того, скільки грошей ви отримали ...

звучить легковажно, але насправді це актуально.

Лише сьогодні у нас виникла проблема, коли запис не вдалося вставити в нашу таблицю оцінок, оскільки одна з колонок (GrossRate) встановлена ​​на десяткові (11,4), а наш відділ продуктів щойно отримав договір на приміщення на якомусь дивовижному курорті в Бора-Борі, які продають за кілька мільйонів тихоокеанських франків за ніч ... те, що ніколи не було антикопійовано, коли схема баз даних була розроблена 10 років тому.

Для облікових програм дуже часто зберігати значення як цілі числа (деякі навіть йдуть так далеко, щоб сказати, що це єдиний шлях). Щоб отримати ідею, візьміть суму транзакцій (припустимо, $ 100,23) та кратну на 100, 1000, 10000 тощо, щоб отримати необхідну точність. Тож якщо вам потрібно лише зберігати центи і можете сміливо округляти вгору чи вниз, просто помножте на 100. У моєму прикладі це зробить 10023 як ціле число для зберігання. Ви заощадите простір у базі даних, а порівняння двох цілих чисел набагато простіше, ніж порівняння двох плавців. Мої 0,02 долара.

супер пізній запис, але GAAP є хорошим правилом.

Якщо у вашій програмі потрібно обробляти кошти до трильйона, це має спрацювати: 13,2 Якщо вам потрібно дотримуватися GAAP (Загальноприйняті принципи бухгалтерського обліку), тоді використовуйте: 13,4

Зазвичай ви повинні підсумовувати свої кошти на рівні 13,4, перш ніж округлювати результат до 13,2.

Джерело: Найкращий тип даних для зберігання грошової вартості в MySQL

Ви можете використовувати щось на кшталт DECIMAL(19,2)за замовчуванням для всіх ваших грошових цінностей, але якщо ви коли-небудь зберігатимете значення, менші ніж 1000 доларів, це просто втратить цінний простір бази даних.

Для більшості реалізацій DECIMAL(N,2)було б достатньо, коли значення Nстановить принаймні кількість цифр до .найбільшої суми, яку ви коли-небудь очікуєте зберегти в цьому полі + 5. Тож якщо ви ніколи не розраховуєте зберігати значення, які перевищують 999999,99, їх DECIMAL(11,2)має бути більш ніж достатньо (доки очікування не зміниться).

Якщо ви хочете бути сумісними з GAAP , ви можете піти з тим DECIMAL(N,4), де значення Nстановить щонайменше кількість цифр до .найбільшої суми, яку ви коли-небудь очікуєте зберегти у цьому полі + 7.

Це залежить від характеру даних. Вам потрібно заздалегідь обміркувати це.

Моя справа

• десятковий (13,4), не підписаний для запису грошових операцій
  • ефективне зберігання (4 байти в кожній стороні десяткової крапки) 1
  • Сумісність із GAAP
• десяткові (19,4) не підписані для агрегатів
  • нам потрібно більше місця для сукупності декількох багатомільярдних транзакцій
  • напіввідповідність типу даних MS Currency не зашкодить 2
  • це займе більше місця на запис (11 байт - 7 ліворуч і 4 праворуч), але це нормально, оскільки є менше записів для агрегатів 1
• десяткова (10,5) для обмінних курсів
  • вони, як правило, цитуються разом із 5 цифрами, щоб ви могли знайти такі значення, як 1.2345 та 12.345, але не 12345.67890
  • це широко розповсюджена конвенція, але не кодифікований стандарт (принаймні, до моїх знань швидкого пошуку)
  • ви можете зробити це десятковою (18,9) з однаковим сховищем, але обмеження типу даних є цінним вбудованим механізмом перевірки

Чому (М, 4)?

• є валюти, які розбиваються на тисячу копійок
• є грошові еквіваленти, такі як "Унідад де Ферменто", "CLF", виражені 4 значними десятковими знаками 3 , 4
• це сумісно з GAAP

Компроміс

• нижча точність:
  • менша вартість зберігання
  • швидші розрахунки
  • нижчий ризик помилки обчислення
  • швидше резервне копіювання та відновлення
• більш висока точність:
  • майбутня сумісність (цифри мають тенденцію до зростання)
  • економія часу на розробку (вам не доведеться перебудовувати половину системи, коли ліміти будуть дотримані)
  • нижчий ризик відмови виробництва через недостатню точність зберігання

Сумісний екстремальний

Хоча MySQL дозволяє використовувати десятковий (65,30), 31 для шкали та 30 для точності, здається, наші обмеження, якщо ми хочемо залишити варіант передачі відкритим.

Максимальний масштаб і точність у найбільш поширених RDBMS:

            Точність шкали
Oracle 31 31
T-SQL 38 38
MySQL 65 30
PostgreSQL 131072 16383

6 , 7 , 8 , 9

Розумний Екстрім

2. Чому (27,4)?
   • ви ніколи не знаєте, коли в системі потрібно зберігати зімбабвійські долари

Вересень 2015 Уряд Зімбабве заявив, що обміняє зімбабвійські долари на долари США за курсом від 1 долара до 35 квадрильйонів зимбабвійських доларів 5

Ми схильні говорити "так, точно ... мені не потрібні ці шалені цифри". Що ж, про це казали і Зімбабвійці. Не давно.

Давайте уявимо, що вам потрібно записати транзакцію в 1 мільйон доларів США в зимбабвійських доларах (можливо, це навряд чи сьогодні, але хто знає, як це буде виглядати через 10 років?).

1. (1 млн. Дол. США) * (35 квадриліон ZWL) = (10 ^ 6) * (35 * 10 ^ 15) = 35 * 10 ^ 21
2. нам потрібно:
   • 2 цифри для зберігання "35"
   • 21 цифра для зберігання нулів
   • 4 цифри праворуч від десяткової коми
3. це робить десятковим (27,4), що коштує нам 15 байт за кожен запис
4. ми можемо додавати ще одну цифру зліва без грошей - у нас десятковий (28,4) на 15 байт
5. Тепер ми можемо зберігати трансакцію в 10 мільйонів доларів США, виражену в зімбабвійських доларах, або захистити від чергової страйку гіперінфляції, яка, сподіваємось, не відбудеться

Хоча це може бути пізно, але це буде корисно комусь іншому. З мого досвіду та досліджень я дізнався і приймаю десятковий (19, 6). Це під час роботи з php та mysql. при роботі з великою сумою грошей і курсом валют