mickburkejnr
mickburkejnr

Reputation: 3690

Are there any performance issues with storing content on a database, instead of on a normal ASPX or PHP page?

Me and a colleague were discussing the best way to build a website last week. We both have different ideas about how to store content on the website. The way I have always approached this has been to store any sort of text or image link (not image file) on to a database. This way, if I needed to change a letter or a sentance I would just need to go on the database. I wouldn't have to touch the actual web page itself.

My colleague agreed with this to a point. He thinks that there are performance issues related to retrieving content from the database, especially if every character of content is coming from the database. When he builds a website, any content that won't be changed often (if at all) will be hard coded on to the page, and any content that would be changed or added regulary would come from the database.

I can't see the benefit of doing it like this, just from the perspective of everytime we make a change to an ASPX page we need to re-compile the site to upload it. So if a page has a misspelt "The" (so it'd be like "Teh") on one page, we have to change it on the page and then recompile the site (the whole site) and then upload it.

Likewise with my colleague, he thinks that if everything was to come from the database there would be performance issues with the site and the database, and that the overall loading speed of the web page to the browser would decrease.

What we were both left wondering was that if a website drew everything from the database (not HTML code as such, more like content for the headers, footers, links etc) would it slow down the website? And as well as this, if there is a performance issue, what would be better? A 100% database driven website with it's performance issues, or a website that contains hard coded content which would mean 10/20 minutes spent compiling and uploading a website just for the sake of a one word or letter change?

I'm interested to see if anyone else has heard of it, or if they have their own thoughts on this subject?

Cheers

Upvotes: 2

Views: 119

Answers (2)

Ronnis
Ronnis

Reputation: 12833

Hardcode the strings in the code (unless you plan to support multiple languages). It is not worth the

  • extra code required for maintaining the strings
  • the added complexity
  • and possibly performance penalty

Would you extract the string "Cancel" from a button? If so, would you be using the same string on multiple cancel buttons? Or one for each? IF you decided to rename one button to "Cancel registration", how do you identify which "Cancel" to update in the database? You would be forced to set up a working process around how to deal with this, and in my opinion it's just not worth it.

Upvotes: 0

James Gaunt
James Gaunt

Reputation: 14783

Naturally it's a bit slower to retrieve information from a database rather than directly from the file system. But do you really care? If you design your application correctly then

a) you can implement caching so that the database is not hit for every page

b) the performance difference will be tiny anyway, particularly compared to the time to transmit the page from the server to the client

A 100% database approach opens up the potential for more flexibility and features in your application.

This is a classic case of putting caching / performance considerations before features / usability. Bottlenecks rarely occur where or when you expect them to - so focus on developing a powerful application and then implement caching later - when it's needed and where it's needed.

I'm not suggesting storing templates as static files is a bad idea - just that performance shouldn't be your primary driver in making these assessments. Static templates may be more secure or easier to edit using your development tools for example.

Upvotes: 3

Related Questions