Yeah, but then surely you'd have to take the union of a potentially large number of tables to display a single-category view, which I suspect is going to remain a more common request than a category-intersection view. Isn't that going to give you a substantial performance hit for large categories?
I'm not sure where you get this idea that each intersection would be a separate table. Obviously it wouldn't, it would still be one single database table, containing everything. And this single table can be queried for a single category, which (assuming proper indexes are in place) would not be any less efficient than it already is currently.
(And incidentally, pages that are only in a single category will have to remain in their own table. You can't get that from intersection tables.)
I admit I forgot about pages that are in a single category, but they can still be placed in the same table (just NULL the second category column for those).
More to the point: if you're maintaining many tables in parallel like this, you need that many more DB calls.
Nope. See above.
Timwi