我有一个SQLite数据库,我在其中修改了一个表以添加一列,该列将包含一种针对每行的永久唯一ID(除了现有的INTEGER PRIMARY KEY
,它可能会被重新分配,因此不是永久的)。我还希望避免意外地混淆正常的ID和新的"永久ID",因此我决定使用TEXT
列,并为每个值赋予前缀,例如pid-
。
因此,我只是添加了一个名为perma_id
的列,类型为TEXT
,并运行UPDATE mytable SET perma_id = 'pid-' || _rowid_
为现有行赋值。然后,我保存并压缩/清空了数据库,并将其压缩到一个zip文件中,因为我将其包含在Android APK中。
我注意到在添加新列之后,文件大小从379kB增加到了417kB。这当然是意料之中的。但是作为一个实验,我想也许我可以通过使用p...
而不是pid-...
作为perma_id
列的值来减少文件大小,所以我重新分配了所有的值。但是令我惊讶的是,文件大小反而 * 增加 * 到420kB!我做了进一步的实验,我可以一致地得到(压缩的)文件大小,pid-...
变为417kB,p...
变为420kB。正如预期的那样,使用INTEGER
列进一步减少了文件大小,但仅减少到414kB。
这让我想知道--在perma_id
列中使用较长的字符串作为前缀时,较小的文件大小背后有什么魔法?有没有办法确定哪个字符串会产生最小的文件大小?
编辑
刚刚尝试使用前缀perma-id-...
,这会导致压缩文件大小为414kB-即与使用前缀后面只有数字的INTEGER
列相同。所以我尝试将very-long-permanent-id-with-the-value-...
作为前缀-413kB。
1条答案
按热度按时间deikduxw1#
每次压缩之前,是否尝试在数据库上运行VACUUM命令?
当您缩短主键值时,它可能会减少数据的大小,但保持.DB文件的大小不变,因为SQLite不会自动减少文件大小,它只是将文件的块标记为“可覆盖”。直到,也就是说,您运行VACUUM来丢弃所有这些备用空间。
我猜你的文件中“可覆盖”的部分很难压缩,然后当它充满了大量重复的文本“permanent-id-with-the-value-”时,压缩就变得容易了!