Databases needn't be frightening, hard or expensive
Archive - Originally posted on "The Horse's Mouth" - 2006-11-08 07:38:24 - Graham Ellis
Have you written a web site using plain old HTML (perhaps with style sheets and images) and then extended it to more interactive content using a little PHP, JSP, Perl, cgi or similar? Are you keeping the data associated with your PHP - your on line programs - in plain text files? If you are, that may be the right decision, or it may be the wrong one. Database engines such as MySQL are available for free download and install, are provided as a standard part of the package by most WSPs (Web Service Provider)s, and can provide - in the right circumstances - an easy, effective and efficient way of storing, accessing and updating data. And those "right circumstances" are so common that they'll apply to elements of most modern web sites.
If you keep data in plain files on your web site / within your application, it'll work fine while the application and the data is small and doesn't change a great deal, but plain files have a number of issues you need to consider:
If you edit a file, you have to rewrite the whole file.
You need to write code to understand the format of the file - strip out comma separators, but allowing for commas within fields, etc.
File locking isn't nice - great care needs to be taken if there's any chance of two concurrent changes being made.
As data grows, the file / directory structure with a very large number of files becomes inefficient and unmanageable.
Searching a file / looking for data becomes all the more inefficient as the data volume grows.
You'll notice that many of the limitations I mention relate to data volume and you might thing to yourself "but I don't have a high traffic level - I don't need to bother". You might be surprised at just how quickly data volumes increase and tip the balance in favour of databases even for a small organisation. At Well House Consultants, we're a team of just 4 full time staff ... and yet without databases and tables, navigating our web site would be like running through treacle.
Even this article, when I post it, will be in a database. As a user of the system, I wouldn't need to know that or to take any special action, but as a user I'll see it filed efficiently. And because it's in a database it will be very easy for me to correct spelling mistakes later without having to pull in all the past articles too, and it also helps make it very, very easy to provide search tools. Have a look at this demo that searches through the title of old entries and see just easy the code is.
I train people on using plain text files. And I train people on databases too. So I have a foot in both camps. When would I recommend a switch to a database for a particular table of information?
When there's a large amount of data
When there's a possible need for concurrent edits
When the data is structured and elements would otherwise be repeated
When there's a need for searching and summarising
... oh - you should consider switching to a database when any one of those conditions applies. And the beauty is that you don't have to put ALL you data in databases - you can still use plain text files where they're appropriate. Our "Message of the day" which appears on our home page is a plain text file. Short, simple, easy to edit, unlikely to be searched and only edited by one person at a time.