I’m refactoring a horribly interwoven db schema, it’s not that it’s overly normalised; just grown ugly over time and not terribly well laid out.
There are several tables (forum boards, forum posts, idea posts, blog entries) that share virtually identical data structures and composition, but are seperated simply because they represent different “objects” from the applications perspective. My initial reaction is to put everything that has the same data structure into the same table, and use a “type” column to distinguish data when performing a select.
Am I setting myself up for a fall by adopting this “all into one” approach and allowing (potentially) so many parts of the application to access the same table? FYI, I can’t see this database growing to more than ~20mb over the next year or so…
I used to dislike this “all into one” approach, but after I was forced to use it on a complex project a few years ago, I became a fan. If you index the table correctly, performance should be OK. You’ll want an index on the type column to speed up your sort by type operations, for instance.
I now usually recommend that you use a single table to store similar objects. The only question then, is, do you want to use subtables to store data that’s specific to a certain type of object? The answer to this question really depends on how different the structure of each object type is, and how many object types you’ll have. If you have 50 object types with vastly differing structures, you may want to consider storing just the consistent object parts in the main table and creating a sub table for each object type.
In your example, however, I think you’d be fine just putting it all into a single table.
For more info, see here: http://www.agiledata.org/essays/mappingObjects.html