Content Segregation is a bad idea
In the past, when building small web applications with up to a couple concurrent users, I’ve placed the database on the same system as the web server. Blasphemy!!!…not really. You see, knowing that database systems will entirely consume their allocated memory allows for clear capacity planning.
There are many factors that need to be taken into consideration when designing an architecture and for the sake of this post lets just say that:
- This system does not require a ridiculous amount of memory
- This system does not require HA
And really, while every project sponsor will tell you that their project requires the most powerful server ever built and for the sake of humanity can never go offline again, most web applications don’t require all that much memory…and the fate of the company is not dependant on 100% uptime…just check the SLA.
So what does this all have to do with “Content Segregation”? Oh, and WTF is “Content Segregation”?
Ok, ok, just one more paragraph to provide context.
Large web applications with high concurrent user counts will commonly separate not only content types across systems but also application modules. For example, there might be a small web server cluster for images or a separate group of servers for the account management modules (login, register, profile). These practices are commonly accepted and I couldn’t agree with them more. Its just that most of the applications I am involved with don’t require this type of advanced architecture even though the project sponsor would have you believe otherwise. These, not the large web applications, are those we need to discuss..
So what does this all have to do with “Content Segregation”? Oh, and WTF is “Content Segregation”?
Until recently performance and availably have been the only reasons I’ve recognized to separate content across physical servers. That is until just very recently, in a meeting of the minds it was stated, as fact, that “Items of content type X are data and should be stored on the database server”
WTF? Let me clarify, not IN the database, but on the database server file system..
Ok, I have my head around what you are saying, I understand that your an advocate of Content Segregation, I just don’t understand why, but I can tell you why not.
1. Performance
Database servers are commonly separate physical systems for performance reasons. The DB server should not be a dumping ground of user generated content. It might seem silly but there is a chance that you might really use the SQL server for something that requires its full power. Maybe some form of analytics and when that happens you need to have the available power.
2. Slippery Slope
I truly hate this argument but it fits so perfect into this context. Its not so far of a leap to go from storing images on the database file system to storing images in the database.
