It makes sense but it can become an expensive operation (as it currently stands) if the database gets large. Right now it would require me to query every single record for each category/status/whatever to see if a bug matching that criteria existed or not. I'd rather keep a separate table that has the bug counts (would be useful on the summary page) that gets updated as each bug changes. That won't happen soon since it would require some database changes and a lot of code addition. If anyone understands DBs and SQL better than I then please speak up.

I'd start by moving the severity, status, resolution etc. to separate tables.


I don't know how costly the cross joins will get, but a [select distinct s.status_id status_ID, s.status_description status_description from Status s left join Bugs on bugs.status_id=s.status_id] should not take too much time. I don't know if it is at all possible to cache queries in PHP/mySQL, but if you could that would help too.

I'll probably check back into this after the 1.0 release. In the menatime I need to read more about db normalization and caching/performance characteristics. Thanks for the start.

Decided against this.