加密每个 sqlite 数据库条目的缺点是什么？

看。

在这里，您已经加密了数据库中的每个条目。

现在你有一个问题：如何找到包含文本“总统是炸弹”的记录。

使用未加密的数据库，一个简单的 SQL 查询就可以工作

SELECT * FROM records WHERE record_text LIKE '%президент%' AND record_text LIKE '%бомба%'

如果所有记录都被加密，那么对于搜索，您需要提取所有记录，解密每个记录，然后检查是否存在所需的单词。

任何尝试使用数据库都会发生这种情况。

也就是说，简单地说，base =- 的强大之处恰恰在于它的记录可以以某种统一的方式（SQL - 查询）被访问。

如果通过加密记录（好吧，在加密的，特别是加密良好的 sql 记录上 - 查询毫无意义）从数据库中消除了这种优势，那么数据库的优势就消失了，您也可以使用包含加密的普通文件数据。

在“工业操作”中，有时会在“整个数据库被加密，但其中的记录没有被加密”的情况下使用这种方法：我们将数据库放置在一个加密的容器中，例如 Vera crypt 卷。输入密钥（或密码）后，容器就被解密、挂载，您就可以使用数据库了。与未加密一样，具有简单数据库的所有优点。

一旦劫匪来了（反之亦然，警察），他们很快就卸载了卷，它变成了一系列伪随机数据。

这种方法的优点是您不需要自己实现加密（这是一项非常困难且非常微妙的任务）：一个现成的实用程序负责加密，并且由一组密钥提供保密性。

如果只加密记录，那么数据库和表的结构是显而易见的。这为研究提供了很大的空间。

另外，由于每条记录都是单独加密的，密码的强度大大恶化——因为现在有一大堆加密数据，其中一些的值可以完全恢复——如果字段包含一个int或一个短字符串（例如，国家名称），那么一切都很强大 - 大大简化了。但是对于程序员来说，它只会变得更加复杂。

如果整个数据库都是加密的，那么解密就会变得更加复杂。尽管在这种情况下，您始终可以尝试捕捉整个表在内存中被解密的时刻并将其转储。但如果基地本身已经泄露，那么解密将更加困难。虽然，您可以使用基本文件的第一个字节非常可预测的事实:)

只是添加到以前的答案。数据库中的加密数据仅用于从外部与它们一起使用，DBMS 本身就愚蠢地变成了存储。DBMS 将无法对这些数据执行任何或多或少的操作，只能执行基本的选择/更新/插入/删除 - 不会为您进行搜索、计算……例如，密码早已被散列，以免被完全恢复。所有 subds 的强项在于处理数据，加密让 subds 变成无人知晓