在SQLite中读取行与列的相对成本是多少？

Question

我试图围绕SQLite数据库创建包装器，以允许从.net应用程序进行无模式访问。 想法是将每个实体简单地视为一个集合或属性值对。

优先考虑的是开发人员的简单性和易用性，而不是性能，但我不想完全忽略内存使用和光盘读取时间。

包装器的体系结构意味着，将为第一个查询至少读取所有主键（然后将其缓存），但是其他属性可以在以后根据需要读取。

问题是，是否最好在运行时为每个属性名称创建一列，然后拉入与请求的属性相对应的列，还是为每个属性创建一个记录，然后拉入所请求的属性的记录。

根据应用程序的本质，我不会事先知道将读取什么顺序的属性以及是否将读取所有属性。

Answer 1

不要重新发明轮子，尤其是当您要更换的轮子已经变圆时。

因此，让我们看看现有的轮子与您尝试重新发明的轮子相比有何不同。

1）现有轮子（带列的表）我们有一个表Entity ，其结构如下：

id    INTEGER PRIMARY KEY
attr1 INTEGER
attr2 REAL -- this holds a date
attr3 TEXT
attr4 TEXT

2）重塑轮子，属性表假设我们将为此创建一个表EntityAttributes以便在1）处保存Entity所有属性，但问题是它将如何？ 我们是否应该将TEXT用作所有属性值的类型，并处理应用程序中的来回转换？ 然后该表可能如下所示：

entity_id  INTEGER
attr_name  TEXT
attr_value TEXT
           PRIMARY KEY(entity_id, attr_name)

实际上，这并不是什么大问题，因为Sqlite在内部将所有内容都存储为TEXT，但是对于任何普通的RDBMS而言，这是一个巨大的损失。

另一种选择是使用支持多种类型的复杂属性表。 可能看起来像：

entity_id  INTEGER
attr_name  TEXT
attr_int   INTEGER
attr_real  REAL
attr_text  TEXT
           PRIMARY KEY(entity_id, attr_name)

还有一种可能，对具有代理键的对（entity_id，entity_name）使用主表，并为每种数据类型使用一个表（该表具有来自主属性表的代理键值作为PK），但是这种情况也变得越来越多。这个讨论很多。

最重要的是，从一开始就需要解决一些问题，当我们选择轮子时需要解决。

现在让我们继续讨论性能。 通常，一行中的所有值都彼此相邻（或接近）存储，因此IO成本通常较低。 不能说多行，特别是如果它们没有一个接一个插入。 您始终可以为数据库文件重新索引以优化访问，但是如果没有逐行创建行，这将无济于事。
该解决方案的另一个缺点是，与自然解决方案相比，它实际上需要更多的存储空间（不是很多，但是更多）。

到目前为止一切都好吗？ 怎么样：您有以下简单的SQL查询：

SELECT id, attr1, attr2
  FROM Entity
 ORDER BY attr1;

尝试使用每行属性的方法来做同样的事情，看看它是多么容易。 这只是一个例子，还有许多其他想法。

与传统的RDBMS相比，属性表解决方案在您的情况下看起来更糟（一次是因为它们在将一行的列值保持在一起方面做得更好，而另一次是因为它们支持与Sqlite不同的实际不同类型）。 在使用键值数据存储（例如Redis）时，情况有所不同。

总而言之，针对每行属性的方法有很多话要说，如果您可以通过使用几列来做到这一点，那么实际上没有任何优势。 属性表在您真正需要它时很有用，就像一些未知的（动态）属性一样，但是在您的情况下，我会选择自然解决方案。