使用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套接字上。如果需要多个writer（多个进程/线程同时写入数据库），那么锁开销可能会更糟，MySQL或PostgreSQL的性能会更好，尤其是在同一台机器上运行时。这三个数据库所支持的基本SQL是相同的，所以基准测试并不是那么痛苦。在

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

至于调试代码，您可以很容易地集中SQL调用并添加跟踪以记录正在运行的查询、返回的结果等。将现有的表类作为SQLite的包装器可能是最简单的。在

我强烈建议不要重新发明轮子。SQLite的bug将少得多，并为您节省大量时间。（您可能还需要了解一下Firefox最近改用SQLite存储历史记录等，我认为他们这样做可以大大提高速度。）

另外，SQLite经过良好优化的C实现可能比任何纯Python实现快得多。在

Answer 2

您可以尝试使用与类表相同的接口来制作一个sqlite包装器，这样您就可以保持代码的整洁并获得sqlite的性能。在

Answer 3

如果你在做数据库工作，使用一个数据库，如果你没有，那就不要。使用表，听起来就像你在做。我建议使用ORM使它更像Python。SQLAlchemy是最灵活的（尽管它不仅仅是一个ORM）。在