python - 使用 sqlite3 与自定义表实现的优缺点

Question

我注意到我的(纯 Python)代码的很大一部分处理表格。当然，我有 class Table 支持基本功能，但我最终会向它添加越来越多的功能，例如查询、验证、排序、索引等。

我想知道删除我的 class Table 并重构代码以使用常规关系数据库是否是个好主意我将在内存中实例化。

到目前为止，这是我的想法:

1. 查询和索引的性能会提高，但 Python 代码和单独的数据库进程之间的通信可能不如 Python 函数之间的通信效率高。我认为这是太多的开销，所以我将不得不使用 Python 附带的 sqlite，并且存在于同一进程中。我希望这意味着它是纯粹的性能提升(以非标准 SQL 定义和 sqlite 的有限功能为代价)。

2. 有了 SQL，我将获得比我自己编写代码更强大的功能。似乎是一个明显的优势(即使使用 sqlite)。

3. 我不需要调试我自己的表实现，但是调试 SQL 中的错误非常困难，因为我无法设置断点或轻松打印出中间状态。我不知道如何判断我的代码可靠性和调试时间的总体影响。

4. 代码将更易于阅读，因为我不会调用我自己的自定义方法，而是编写 SQL(需要维护此代码的每个人都知道 SQL)。然而，处理数据库的 Python 代码可能比使用纯 Python class Table 的代码更丑陋和更复杂。同样，我不知道哪个更好。

对以上内容有任何更正，或者我应该考虑的其他事项吗？

Answer 1

SQLite 不在单独的进程中运行。所以你实际上没有任何来自 IPC 的额外开销。但是 IPC 开销并没有那么大，尤其是在 UNIX 套接字上。如果您需要多个写入器(多个进程/线程同时写入数据库)，锁定开销可能会更糟，而 MySQL 或 PostgreSQL 的性能会更好，尤其是在同一台机器上运行时。这三个数据库支持的基本 SQL 都是相同的，因此基准测试并不那么痛苦。

您通常不必像调试自己的实现那样对 SQL 语句进行相同类型的调试。 SQLite 可以工作，并且已经调试得相当好。您不太可能需要调试“好的，该行存在，为什么数据库找不到它？”并追踪索引更新中的错误。调试 SQL 与过程代码完全不同，而且实际上只发生在非常复杂的查询中。

至于调试你的代码，你可以相当容易地集中你的 SQL 调用并添加跟踪来记录你正在运行的查询、你得到的结果等。Python SQLite 接口(interface)可能已经有这个(不确定，我通常使用 Perl)。将现有的 Table 类作为 SQLite 的包装器可能是最简单的。

我强烈建议不要重新发明轮子。 SQLite 将有更少的错误，并为您节省大量时间。 (您可能还想查看 Firefox 最近切换到使用 SQLite 来存储历史等，我认为他们这样做得到了一些非常显着的加速。)

此外，SQLite 的优化 C 实现可能比任何纯 Python 实现快得多。