在我的应用程序中，作为用户，他们的帐户上最多可以有64枚奖牌。
每个奖牌的值从0到3(取2位)。
问题：我应该如何将奖牌值存储在数据库中？
选项1:
USER_ID MEDAL0 MEDAL1 MEDAL2 ... MEDAL64
1 0 1 2 0
选项2:
USER_ID MEDALS
1 blob
此外，奖牌被分成8个部分，通常会放在一起，所以它们可以像这样组合在数据库中，但将比特连接成一个整数：
USER_ID MEDALS1 MEDALS2 MEDALS3 ... MEDALS8
1 200260 2332 69188 0
所以我的问题是，这些选项在SQLite性能(速度和较小程度的内存)方面有何不同？64列包含4位INTEGER可以吗？最好有8列大整数？
至于速度。速度有三种。写入速度(W)，包括初始写入和更新、读取速度(
R。
我更喜欢选项1。
使用选项1，您可以获得最快的R和p，因为当您需要读写奖牌时，只需选择并更新相应的字段。对于选项2,3，您必须读取额外的位。当您需要写入时，必须读取旧位，更新它并保存新的组合值。
初始W乍一看可能很慢，但实际上并非如此。Sqlite将检测数字的大小，并以最紧凑的方式存储它。
在SQLite数据类型页面的第1.0节中，它详细介绍了如何存储和检索INTEGER值。该段的结果是，整数可以以特定的长度存储，但当它们在内存中使用时，它们是64位(有符号)整数。
选项2可能是最灵活的。你可以添加更多等级的奖牌(3+位)，以及更多的奖牌。它也可能比处理某种整数更不方便。
选项1
有64列包含4位INTEGER可以吗？
整数的最小存储类是磁盘上的1字节，因此除了运行时未使用的空间外，还有一半的空间将被浪费。但从编程的角度来看，这可能是最容易处理的。
对于选项3，我至少会考虑使用更大的整数大小(UNSIGNED BIGINT，64位)来减少粘贴位。
我至少会试试选项1。SQLite是相当快的，它至少会让你走。