Development

A well designed system wold not need to use OPTIMIZE TABLE all over the place to handle variable btye field fragmanetation.

If you had a forum system for instance, it would be an idea to make one table for the basic post info, and make it a fixed with including the subject string. You would then have a realted table for posts. you can use JOIN's to put content back together. With proper indexing, things like the view of forum indexes (which are demanding and have lots of hits), would be fast as it would not have to work on fragmented tables. Admittedly you might want to optimize the table with post data, however the system would be faster overall and would not need to have OPTIMIZE TABLE like Tiki does.

Why should you rely on MySQL's cache ? That's just bad, because you are just relying on a cache because you can't be bothered as a development team to make your code clean.

If Tiki had to have it's database put on a separate server, I'd hate to see it work, as with 200 queries in a page, you would make so much network traffic and put so much data contention on the network, not to mention it would be so slow. It's bad enough on this server, which obviously runs MySQL on the same system as the webserver (and no doubt this is a Linux system where IPC communication is fast)