In a discussion board there are generally many more posts, than topic headlines (titles). IMO it would be a cleaner practice to treat headlines as posts, but wouldn't it put serious penalty on performance if MySQL searches through every post to catch the headlines?
Making a seperate table for the headlines would certainly increase the performance, but I feel that it adds an unnecessary complexity.
What side should I choose of this performance-cleanliness trade-off?
You can simply have an "is_headline" column with an index that starts with that column aimed at "headlines only" queries.
That would be OK performance while avoiding complexities of 2 table design.
I would go with the simpler solution (considering headlines as posts -- which you hsould only do if those two share most of their properties and behaviors), at least until you really have performance problems.
And, if you do have performances problems, there are probably easier solutions to optimize, like :
I might add, like Donald Knuth said :
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
If, one day, you really are experiencing performances problems, maybe that day it'll be time to try that kind of ideas... But as long as you don't need it... Why go through all that kind of trouble ?
And, even then, it might be cheapier to add more cache, or throw a second server into the game, than re-think that kind of thing -- and the performance benefits might be far better, actually !
It depends on what features your headlines share with the posts. It may be that headlines are distinct enough that it is better to keep them independent. Additionally, consider that you can use your headline rows as a denormalized performance improvement (update "most recent post" time, user and preview to the headline and you don't need to dig for that on the front page queries).
Don't design tables based on performance considerations. Performance is important, but you need to get the logical model right before you begin worrying about performance. A wrong logical model results in endlessly contorted code, lots of bugs, long development times, and, eventually, slow performance.
...what Knuth said.
A table design that is both right and relevant can be worked with to get you the performance you need. You've got indexes, you've got table partitions, you've got oodles of tools that can fine tune the database without impacting the application.