Question

I noticed that a significant part of my (pure Python) code deals with tables. Of course, I have class Table which supports the basic functionality, but I end up adding more and more features to it, such as queries, validation, sorting, indexing, etc.

I to wonder if it’s a good idea to remove my class Table, and refactor the code to use a regular relational database that I will instantiate in-memory.

Here’s my thinking so far:

1. Performance of queries and indexing would improve but communication between Python code and the separate database process might be less efficient than between Python functions. I assume that is too much overhead, so I would have to go with sqlite which comes with Python and lives in the same process. I hope this means it’s a pure performance gain (at the cost of non-standard SQL definition and limited features of sqlite).

2. With SQL, I will get a lot more powerful features than I would ever want to code myself. Seems like a clear advantage (even with sqlite).

3. I won’t need to debug my own implementation of tables, but debugging mistakes in SQL are hard since I can’t put breakpoints or easily print out interim state. I don’t know how to judge the overall impact of my code reliability and debugging time.

4. The code will be easier to read, since instead of calling my own custom methods I would write SQL (everyone who needs to maintain this code knows SQL). However, the Python code to deal with database might be uglier and more complex than the code that uses pure Python class Table. Again, I don’t know which is better on balance.

Any corrections to the above, or anything else I should think about?

Answer 1

SQLite does not run in a separate process. So you don’t actually have any extra overhead from IPC. But IPC overhead isn’t that big, anyway, especially over e.g., UNIX sockets. If you need multiple writers (more than one process/thread writing to the database simultaneously), the locking overhead is probably worse, and MySQL or PostgreSQL would perform better, especially if running on the same machine. The basic SQL supported by all three of these databases is the same, so benchmarking isn’t that painful.

You generally don’t have to do the same type of debugging on SQL statements as you do on your own implementation. SQLite works, and is fairly well debugged already. It is very unlikely that you’ll ever have to debug “OK, that row exists, why doesn’t the database find it?” and track down a bug in index updating. Debugging SQL is completely different than procedural code, and really only ever happens for pretty complicated queries.

As for debugging your code, you can fairly easily centralize your SQL calls and add tracing to log the queries you are running, the results you get back, etc. The Python SQLite interface may already have this (not sure, I normally use Perl). It’ll probably be easiest to just make your existing Table class a wrapper around SQLite.

I would strongly recommend not reinventing the wheel. SQLite will have far fewer bugs, and save you a bunch of time. (You may also want to look into Firefox’s fairly recent switch to using SQLite to store history, etc., I think they got some pretty significant speedups from doing so.)

Also, SQLite’s well-optimized C implementation is probably quite a bit faster than any pure Python implementation.