So you can see that the number of combinations would get to be quite a lot. I would propose writing them into the categorylinks table
Wait, write an *exponential* number of combinations into the categorylinks table?
I don't think any more than the square is actually necessary, and if not, at most the cube.
The reason we think the SQL is too inefficient is because there can be large numbers of articles in one category. If we store all intersections of two categories, which is easy to do and doesn't take much space at all, then each intersection will likely be small enough to make the SQL for three-way intersections economical, so higher-order intersections need not be stored directly.
Besides, I think you're all forgetting that if we have a table that stores, say, all two-way category intersections, we can actually get rid of the categorylinks table itself -- it would be contained within that new table and would be wholly redundant. Similarly, a table with all three-way intersections contains in it all two-way intersections as well.
Lastly, you're also forgetting that the size of the table is irrelevant as long as the hardware to store it is available. The processing power required to access such a large table is NOT, as is commonly assumed, proportional to the size of the table! This is what databases have indexes for, and it is my understanding that in modern RDBMSs, the time taken to access a record in the table is not directly correlated to the size of the table at all (only to the size of the index, but even then not proportionally).
Timwi