The problem: In 3.3 a new flat-file database was created with the simple objective of tracking an entry's assigned categories, which was essentially tacked on as an afterthought and poorly implemented. It's worth noting, that the categories themselves have always used a flat-file database, but already had code to manage them. Unfortunately the code for managing these flat-file databases in a more unified way has never been fully realized.
The solution: The databases must be easily maintained and be able to grow without negative impact to overall performance. So, update_db, update_maindb, delete_db, resort_db, and resort_catdb were created as new library functions that provide a unified approach to managing flat-file databases. The last two are probably the most involved, running the sort command on the database, but still far more efficient than globbing through a for loop.
So far, I'm satisfied with the results and the obvious gain in speed. Although, I imagine anything would beat having to regenerate a database of a thousand entries or more everytime you want to change a weblog entry. I also had the joy of discovering some strange logic behind the build_weblog, paginate and delete functions.
If you really, really want to comment, please mail n1xt3r@fastmail.fm