64ビットのunsignedintである値があり、それらをunsignedint型を持たないmongodbに格納する必要があります。それらを他のフィールドタイプに保存し、出入りを変換するための3つの主な可能性があります。
署名されたintを使用するのがおそらく最も簡単で、スペース効率が最も高いですが、人間が読めないという欠点があり、誰かが変換を忘れると、一部が機能し、エラーがわかりにくくなる可能性があります。
生のバイナリは、経験の浅いプログラマーにとっておそらく最も扱いにくく、人間が読めないという問題もあります。
文字列表現はスペース効率が最も低くなります（ユニコードで最大40バイト、フィールドあたり8バイト）が、少なくともすべての可能な値が適切にマップされ、クエリでは、より複雑な変換ではなく、文字列への変換のみが必要になります。
これらの値をさまざまなプラットフォームから利用できるようにする必要があるため、単一のドライバー固有のソリューションを選択することはできません。
私が見逃した主な長所と短所はありますか？どちらを使いますか？
I'd just shove the numbers into strings. It's the easiest and the most compatible solution. Most common programming languages provide string to number conversation in their standard libraries. If someone else needs to read your database with a different program later they don't need to figure out your binary storage format. Another bonus is you can store numbers larger than an unsigned int64 if you need to.
文字列値をUnicodeにする必要があるのはなぜですか？値は常に数字になることがわかっているので、20バイト以下を意味する標準のvarcharを使用できます。正直なところ、それは実際に値がどのように使用されるかに依存します。unsigned 64 intを使用しているソースへの多くの結合で使用されますか？その場合、各行に変換が必要になります。（mongodbへの結合ではなく）参照または特定の値のフィルターにのみ使用されますか？その場合、文字列値は十分に機能します。
別の解決策は、可能であれば、64unsignedintの署名付きバージョンを表す64signedint列をmongodbに追加してから、データベースでsignedintを使用することです。このようにして、リンゴとリンゴを結合し、あるシステムの値を別のシステムと比較することができます。
あなたが言ったことを考えると、varchar列は十分に機能し、値を人間が読める形式にするだろうと私はまだ主張しています。
編集別の解決策は、値を符号付き64ビットintに格納し、ユーザーが値を確認できるように、符号なし64ビット値を計算するメソッドをアイテムに追加することです。
私はバイナリで行くと言うでしょう-それはクエリでソート順を正しく取得することが簡単になる上記の唯一の解決策です。