MongoDB v2.6の時点では、固定小数点タイプはありません。データは別のタイプのフィールドに保存する必要があり、アプリケーションは毎回翻訳を実行する必要があります。
潜在的に、中間ライブラリは、アプリケーションの代わりにこの翻訳を行うことができます。 net.liftweb.recordはそうではないと思います。
問題のフィールドにダブルタイプで十分な場合は、簡単にするためにダブルタイプに変更することをお勧めします。ただし、正当な理由でBigDecimalを使用していると仮定すると、よく知られている回避策があります。これらは次のとおりです。
（1）文字列として保存 。任意の精度を持つことができます。ただし、正確な値の一致の並べ替えまたはクエリは、左側にゼロを毎回固定長で埋める場合にのみ機能します。それでも、正の数と負の数は、ソートに関して2つの異なる範囲です。正しい数値ソートを行うには、ネガを逆にソートする必要があります。 MongoDBの順序の例では、当然、これらのゼロが埋め込まれた文字列番号が返されます。
"-0000054321.9876"
"-0000100322"
"0000054321.9876"
"0000100322"
BigDecimal型には文字列値からのコンストラクターがあると思います。したがって、これはアプリケーションの変換関数に実装するのが最も簡単かもしれません。
（2）シフトロング（Int64）として保存 。並べ替えが機能し、使用されるディスク容量が少なくなり、負のv.sで問題は発生しません。ポジティブ。値を固定倍数だけ上にシフトする必要があります。これにより、データベースを直接表示すると少し読みにくくなります。コレクション全体のすべての値で同じになるように精度を固定する必要があります。財務上のユースケースでは問題ありません。一部の科学的なユースケースでは問題があります。
（3）数字のペアとして保存 、小数点のいずれかの側に1つ。並べ替えには、余分な作業が必要です。 Int32数値を使用する場合、精度は小数点以下9桁に制限されます。もちろん、データベース内の1つではなく2つの列を確認するのは、もう少し手間がかかります。
Scalaのコード例として、MongoDBプロジェクトのReactiveドライバーがBigDecimalの3つのシリアル化の回避策 。最初はdoubleを使用します。後者の2つは、さらに別のアプローチを採用しています。BigDecimal値のサブドキュメント全体を作成します。サブドキュメントにラップされた値をクエリしようとすると、注意が必要だと思います。
別の実際のケース Ebay開発チームのブログ（Morphia / Java）から
P.S.おそらくMongoDBは将来的に10進型を追加するでしょう。視聴/賛成できるオープン機能のリクエストがあります-