加密货币MySQL数据类型？

钟青乐

在SQL数据库中存储货币值时有关数据类型的臭名昭著的问题。
但是，在这些艰难的时期，我们现在拥有的货币最多可保留18位小数（感谢ETH）。
现在，这重新提出了经典论点。
, ^! v' W: P& w: b8 E4 |想法
选项1 BIGINT使用一个大的整数，以节省的实际价值，然后存储货币有多少位小数有（简单地将A通过10^B中译本）？
选项2 Decimal(60,30)将数据类型存储在一个大的十进制数中，这不可避免地会占用大量空间。
( }- S0 u: F+ H2 Q* s选项3 VARCHAR(64)以字符串形式存储。这会对性能产生影响。
# a, W# J2 T4 z9 m
3 l' ]+ h" p2 n2 j. V, Q- P我想知道人们的想法，以及他们在处理加密货币值时正在使用什么。我为最好的方法感到困惑。
, ^+ C, \: v5 w# A' P               
解决方案:
               


& t7 r0 b/ h2 g) G3 F8 U                在您建议的三个中，有一个明显的最佳选择（在注释中加上一个）。
; m8 E! u. X. B/ U- ?BIGINT 仅使用8个字节，但最大的BIGINT只有19个十进制数字; 如果除以10 18，则可以代表的最大值是9.22，该范围还不够。
! `  S; z1 @- m+ t1 E  y: r) Z' h, EDOUBLE ”仅具有15’-17的十进制数字；具有浮点运算的所有已知缺点。
5 Z: D, M& W& E9 t8 l*如果您要处理的小数点后18位，则 *VARCHAR 将使用20+字节;
7 @* c* S8 U9 [& s5 q将需要不断的string鈫攊nt转换；无法排序；无法比拟的；不能在数据库中添加；许多缺点。
$ e8 ^+ Q- x8 g! NDECIMAL（27,18）
‘（如果使用MySQL，则将占用12个字节（每9个数字组为4个字节）。这是一个相当合理的存储大小，并且具有足够的范围来支持多达十亿个或小至一个Wei的数量。可以在数据库中对它进行排序，比较，添加，减去等，而不会损失精度。
& R" w# a& s1 p- G( L/ z7 U我会使用DECIMAL(27,18)（或者DECIMAL(36,18)如果您需要存储真正的巨大价值）存储加密货币货币价值。