When i did a systems analysis module in my years at university, i was doing my computer science degree.
One thing our lecture told us all at the time was something we couldn't comprehend.
"Strictly speaking, there is no wrong or right way to approach DBs"
As computer scientists this is hard to swallow.
lets look at your example:
Ok, so you have entities that are similar. They only differ on lets say, a "type".
So your idea is to use one table, then use this "type" field to differentiate. Any extra columns that a blog may have will simply be null in the others.
Pros? Easy to manage, easy to query, removes duplicating fields, you could say this is the correct way.
Cons? Field growth is large (messy), Table size is vast, lots of null-able cells, multiple access has a strong potentials to cause problems updating the table. So, in a way, your way is also wrong.
So taking the basic evaluation there is no wrong way, there is no right way in the rational sense of thinking most programmers love. This is unfortunately its right if it suits your needs.
You need to think about impact. Ok i gain super simple query's, this helps me if im doing some reporting, great stuff. What if this website has large volumes of traffic? you going hit a world of problems having one "super" table of data.
The best methodology I approach DBs is to go against the current fashion of what code 1st approach trys to do. First stop thinking you can throw programming concepts at it. duplicate data is fine depending on reasoning. (please note, this actually rarely happens if you stick to good principles and use normalization correctly, however you can still do this if it suits your needs)
Start normalizing your entity's, you already know what they are, start breaking them down, all the while keeping a record of the layout (usually a diagram of sorts is best). once you have these base entitys start the process of normalizing those entity's further, just be careful not to over normalize.
While from a code perspective this seems alot of work, you have some complex query's to produce. This is the clash, data should be attainable, it should be used, look at expected traffic to drive your DB design, general concept is high traffic = more normalization, low traffic = less.
Finally, to your questions, will it hurt performance? Yes, however the cost of table indexing vs relational joins (assuming relations db design) is a whole issue on its own that needs looking into.
while you gain simple querys and less code, the performance difference isnt that different that anyone would expect you will be suprised, however the real issue is locks, even with appropiate indexs, there will be immense locks taking place, when this starts to happen you will see huge performance losses, and annoying logs!
yes your code will reduce but the pressure on you db is increased, if performance isnt and issue however then the is nothing stopping you doing it that way.
My opinion? again let me stress this is all opinion based, there really is no wrong or right way, there are alot of factors involved for your model. However i would split your entitys up, create your diagram to show the layout.
hope this hasn't confused you, DBs are a funny thing where 1 and 0, true false doesnt really apply to approach. generally though i lik to think of 2 things, performance vs maintainability.