web-dev-qa-db-ja.com

MySQLデータベースに通貨値を保存するのに最適なデータ型

通貨値に最適なSQLデータ型は何ですか？私はMySQLを使用していますが、データベースに依存しないタイプを好みます。

mysqlsqlsqldatatypes
204
Brian Fisher

ほとんどの場合、Decimal(19,4)のようなものは通常かなりうまく機能します。保存する必要がある数値のニーズに合わせて、スケールと精度を調整できます。 SQL Serverでも、「money」は非標準なので使用しない傾向があります。

223
Kibbee

注意する必要があるのは、あるデータベースから別のデータベースに移行する場合、DECIMAL（19,4）とDECIMAL（19,4）が異なることを意味する場合があります

（ http://dev.mysql.com/doc/refman/5.1/en/precision-math-decimal-changes.html ）

 DBASE：10,5（整数10、小数5）
 MYSQL：15,5（15桁、整数10（15-5）、小数5）
47
SeanJA

アサフの応答

獲得した金額に依存します...

軽快に聞こえますが、実際には適切です。

列の1つ（GrossRate）が10進数（11,4）に設定されており、製品部門がすばらしいリゾートの部屋の契約を結んだため、レートテーブルにレコードを挿入できないという問題が今日だけありましたボラボラでは、1泊あたり数百万太平洋フランで販売されています。データベーススキーマが10年前に設計されたとき、それは決して予防されませんでした。

17
Scott Ferguson

また、計算に必要な小数点以下の桁数を計算することも重要です。

私は、100万株の価格の計算を必要とする株価アプリケーションに取り組みました。引用された株価は、7桁の精度で保存する必要がありました。

17
Leah

会計アプリケーションの場合、値を整数として保存することは非常に一般的です（onlyの方法であるとまで言う人もいます）。アイデアを得るには、必要な精度を得るために、トランザクションの量（100.23ドルと仮定します）と100、1000、10000などを掛けます。したがって、セントを格納するだけで安全に切り上げまたは切り捨てできる場合は、100を掛けるだけです。この例では、格納する整数として10023が作成されます。データベースのスペースを節約し、2つの整数を比較することはmuch 2つのfloatを比較するよりも簡単です。私の0.02ドル。

11
Dane Bendixen

超遅刻です​​が、GAAPは良い経験則です。

アプリケーションが1兆までの金額を処理する必要がある場合、これは機能するはずです：13,2

通常、出力を13,2に丸める前に、13,4で金額を合計する必要があります。

ソース： MySQLに金額を保存するのに最適なデータ型

8
Damian

すべての通貨値にデフォルトでDECIMAL(19,2)のようなものを使用できますが、1,000ドル未満の値のみを保存する場合、貴重なデータベーススペースの無駄になります。

ほとんどの実装では、DECIMAL(N,2)で十分です。Nの値は、少なくともそのフィールド.に格納されると予想される最大合計の+ 5の前の桁数です。したがって、999999.99を超える値を格納する予定がない場合は、DECIMAL(11,2)で十分です（予想が変更されるまで）。

GAAP に準拠したい場合は、DECIMAL(N,4)を使用できます。ここで、Nの値は少なくともそのフィールド.に格納されると予想される最大合計の+ 7の前の桁数。

5
John Slegers

データの性質に依存します。事前に熟考する必要があります。

私の場合

  • マネートランザクションを記録するためのdecimal（13,4）符号なし
    • ストレージ効率（とにかく小数点の両側に4バイト） 1
    • GAAP準拠
  • decimal（19,4）集合体の符号なし
    • 複数の数十億のトランザクションの合計のためにより多くのスペースが必要です
    • mS Currencyデータ型の準準拠は害になりません 2
    • レコードごとに多くのスペースが必要になります（11バイト-左が7つ、右が4つ）が、集計用のレコードが少ないためこれは問題ありません 1
  • 為替レートのdecimal（10,5）
    • 通常は5桁で全体が引用されているため、1.2345および12.345のような値を見つけることができますが、12345.67890を見つけることはできません。
    • それは広まった慣習ですが、成文化された標準ではありません（少なくとも私のクイック検索の知識には）
    • 同じストレージで10進数（18,9）にすることもできますが、データ型の制限は組み込みの検証メカニズムとして価値があります

なぜ（M、4）？

  • 千ペニーに分割される通貨があります
  • 「Unidad de Fermento」、小数点以下4桁で表される「CLF」などの通貨相当物があります、 4
  • gAAPに準拠しています

トレード・オフ

  • 低精度：
    • より少ない保管コスト
    • より速い計算
    • 計算エラーのリスクが低い
    • より迅速なバックアップと復元
  • より高い精度：
    • 将来の互換性（数値は増加する傾向があります）
    • 開発時間の節約（制限が満たされた場合、システムの半分を再構築する必要はありません）
    • 保管精度が不十分なために生産が失敗するリスクが低い

互換性のあるエクストリーム

MySQLではdecimal（65,30）を使用できますが、転送オプションを開いたままにしたい場合、スケールに31、精度に30が制限のようです。

最も一般的なRDBMSの最大のスケールと精度：

 Precision Scale 
 Oracle 31 31 
 T-SQL 38 38 
 MySQL 65 30 
 PostgreSQL 131072 16383

6 、 7 、 8 、 9

合理的なエクストリーム

  1. なぜ（27,4）？
    • システムがジンバブエドルをいつ保管する必要があるかわかりません

2015年9月ジンバブエ政府は、ジンバブエドルを1米ドルから35兆ドルのジンバブエドルのレートで米ドルに交換すると発表しました 5

私たちは「ええ、確かに...私はそのクレイジーな数字は必要ありません」と言う傾向があります。まあ、ジンバブエ人もそれを言っていました。ずっと前ではありません。

ジンバブエドルで100万米ドルの取引を記録する必要があると想像してみてください（今日はおそらくそうではないかもしれませんが、これから10年後にはどのように見えるか誰が知っていますか？）。

  1. （100万米ドル）*（35 Quadrylion ZWL）=（10 ^ 6）*（35 * 10 ^ 15）= 35 * 10 ^ 21
  2. 必要なのは：
    • 「35」を保存するための2桁
    • ゼロを保存する21桁
    • 小数点の右側4桁
  3. これにより、decimal（27,4）になり、各エントリに15バイトかかります
  4. 費用なしで左側にもう1桁追加できます-15バイトのdecimal（28,4）があります
  5. ジンバブエドルで表された1,000万米ドルの取引を保存できるようになりました。
3
kshishkin

これは遅くなるかもしれませんが、他の誰かに役立つでしょう。私の経験と研究から、decimal（19、6）を知り、受け入れるようになりました。大量のお金と為替レートを扱う場合

0
precious