I did send a reply to Alex last night--something seems to have dropped it on the floor; I don't know if it's on my side or the list software. Brion's mail seems to imply the latter, but since it hasn't happened to me other times that I rememeber, I'll reserve judgment.

At any rate, thanks, Alex, for pointing out that my new namespace fields were not indexed. I also strongly agree that NOW is exactly the right time to think about tweaking the database structure--all the infrastructure is in place now, but little of the hairy structure-sensitive code of the special pages is written, and the new codebase is well-enough encapsulated that making database changes should be easy. Finally, the new code already requires a database upgrade, so that's no excuse not to do other useful changes. I'm updating the conversion script as as I go.

To test my assumption of encapsulation I did in fact replace the namespace fields in both the "cur" and "old" tables with integers. This should keep the database smaller and speed it up. Making the change took a lot less time than updating the database itself, so it looks like the new codebase passed that test.

I'm also not thrilled with the linked/unliked tables. I'm thinking of replacing them with a single "X links to Y" table using integer indexes.

I'm also open to suggestions about how to change cur_ind_title.

Finally, I mostly agree with Axel's contention that "approval" of articles is just metadata--the piece of information that person X approved of article Y should just be stored somewhere, and used when needed to make collections or whatever. I would call the users authorized to make such approvals "editors", rather than "sysops"--the latter seems more like the folks who can do techie things like direct database access, etc.

Doing that would be easier with yet another database change I considered earlier--replacing the odd linked-list mechanism of old page versions seems awkward. It could be replaced by simply using revision numbers that would be common to both the "cur" and "old" tables. Or an even more radical change--merge both of those tables in to one, and create a "current_revision" table. Ideas?