Separate.

I don't know of any cons but the pros are many. Smaller tables, corruption in one doesn't bring down the others, adding/deleting modules doesn't require downtime for the entire system and on and on.

JAG

Con: If you later decide you need to add a field (or change the structure of an existing field) to all the tables, you'll have to add/modify each table instead of one central table.

For example, let's say that several months down the road you realize that you really should have included logging the IP address with each post. Now you have to go back and add an IPAddress field to every relevant table.

Con: If you have a search capability, you have to search multiple tables instead of just one.

For example, you delete a user who has been spamming your site. You have to go through every table and delete his messages.

Con: If you later decide you need to add a field (or change the structure of an existing field) to all the tables, you'll have to add/modify each table instead of one central table.
For example, let's say that several months down the road you realize that you really should have included logging the IP address with each post. Now you have to go back and add an IPAddress field to every relevant table.

Con: If you have a search capability, you have to search multiple tables instead of just one.

For example, you delete a user who has been spamming your site. You have to go through every table and delete his messages.

All true...unless you use triggers ;-)

JAG

Thanks for the input. I've decided to go with a single content table. I like the idea that it makes searching easier. Also, it enables me to write a self-adapting universal content composer, which will cut down on coding by a factor of about 9:1. It will also simplify security as I will only have to batten down one point of content entry as opposed to 13 points of entry (one for each type of content).

I've decided to go with a single content table.

Be sure to let us know how it works out for you :-)

JAG