使用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接口可能已经有了这个（不确定，我通常使用Perl）。将现有的Table类作为SQLite的包装器可能是最容易的。

我强烈建议不要重新发明轮子。 SQLite将会有更少的错误，并为您节省大量时间。 （你可能也想看看Firefox最近转向使用SQLite存储历史记录等等，我认为这样做会有一些非常显着的加速。）

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

Answer 2

您可以尝试使用与类Table相同的接口创建一个sqlite包装器，这样您就可以保持代码干净并获得sqlite性能。

Answer 3

如果您正在进行数据库工作，请使用数据库，如果不是，则不要。使用表格，听起来就像你一样。我建议使用ORM使它更加pythonic。 SQLAlchemy是最灵活的（虽然它不仅仅是一个ORM）。