As a general rule, you want to index any fields that are going to be used as discriminators in queries - in WHERE, GROUP, etc.
You might also consider adding a synopsis as a reduced set of the textbody and keywords that you (or someone) might use to identify the row of tb_main. These might be indexed as FULLTEXT to facilitate searching.
Whether this is a "good design" just depends on how much complexity you want to add to the design. I can think of lots of ways to search a collection of magazine articles. Each way might lend itself to a different index or a different collection of related tables.
If you want to look at a good paradigm for this design, consider the Bulletin Board software. Each post is like a little magazine article, and they are grouped into categories with keywords, moderator control, responses, etc. Very useful data structures!
Best regards, ~Ray
Main Topics
Browse All Topics





by: fiboPosted on 2009-10-31 at 09:22:29ID: 25710309
1 - Note that is also a FK
2 - For performance, I would probably index PKs (of course) and FKs
Depending on your requirements, in tb_main 'source' might be a FK as well, aind if yo should probably be indexed.
And depending on your content, ypou'll probably add some index on other fields in tb_main (date seems a mandatory candidate!)
3 - It seems today useful to be able to add "tags" to photos or texts... so another table would be needed for that, as well as a FK in tb_main... but you will probably want extra tables for users who created recors in tb_main and/or visitors