Question

在我的申请中，因为用户的帐户最多可以获得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列大型INTEGER？

Answer 1

至于速度。有3种速度。写入速度（ W ），包括初始写入和更新，读取速度（ R ）和程序写入速度（ P ）。

我希望选项1 。

使用选项1，您可以获得最快的 R 和 P ，因为当您需要读取和写入奖牌时，您只需选择并更新相应的字段。使用选项2,3，您必须读取其他位。当你需要写作时，必须阅读旧位，更新它并保存新的组合值。

初始W 乍一看似乎很慢但实际上并非如此。 Sqlite将检测数字的大小并以最紧凑的方式存储它。

Answer 2

在SQLite datatypes page, section 1.0上详细介绍了如何存储和检索INTEGER值。该段的结果是整数可以以特定长度存储，但当它们在内存中使用时，它们是64位（带符号）整数。

选项2可能是最灵活的。您可以添加更多类别的奖牌（3+位）和更多奖牌。它也可能比处理某种整数更不方便。

选项1

64列是否可以包含4位INTEGER？

整数的最小存储类是磁盘上的1个字节，因此除了运行时未使用的空间外，还会浪费一半的空间。但从编程角度来看，这可能是最容易处理的。

对于选项3，我至少考虑使用更大的整数（UNSIGNED BIGINT，64位）来减少粘贴位。

我至少尝试过选项1. SQLite速度相当快，至少可以帮助你。