I am refactoring a horribly intertwined db schema, it isn't it's excessively normalised just grown ugly with time and never terribly well organized.

You will find several tables (forum boards, forum posts, idea posts, blog records) that share virtually identical data structures and composition, but they are seperated since they represent different "objects" in the programs perspective. My primary reaction would be to put exactly what has got the same data structure in to the same table, and employ a "type" column to differentiate data when carrying out a choose.

Shall We Be Held setting myself up for any fall by implementing this "all into one" approach and permitting (potentially) a lot of areas of the applying to gain access to exactly the same table? FYI, I can not check this out database growing to a lot more than ~20mb within the the coming year approximately...

There's essentially 3 ways to keep an item inheritance hierarchy inside a relational database. Each one has their very own benefits and drawbacks. See:

The book is excellent too. Luck might say that chapter 3 - "Mapping to Relational Databases" - is available freely as a sample chapter. Read much more about the tradeoffs inside.

I did previously dislike this "all into one" approach, but after We had to apply it to an intricate project a couple of years back, I grew to become an admirer. Should you index the table properly, performance ought to be OK. You will want a catalog around the type column to accelerate your sort by type procedures, for example.

Now i usually recommend that you employ just one table to keep similar objects. The only real question then, is, would you like to use subtables to keep data that's specific to some certain kind of object? The response to this really is dependent how different the dwelling of every object type is, and just how many object types you will have. For those who have 50 object types with greatly varying structures, you might want to consider storing only the consistent object parts within the primary table and developing a sub table for every object type.

Inside your example, however, I believe you would be fine just putting everything right into a single table.

For more information, see here: http://www.agiledata.org/essays/mappingObjects.html

Don't lean an excessive amount of around the "programs perspective", it has a tendency to vary with time anway. Frequently databases are utilized by different programs too, also it usually outlives all of them ...

When simliar objects are saved in various tables the main reason might be they really represent exactly the same domain object, however in another condition, or perhaps in another part of a workflow. It frequently is sensible to ensure that they're in a single table and then add simple characteristics to flag the condition. When the workflow, or anything changes, it's simpler to alter the database and application too, you might not have to increase the tables or classes.