Are there any real benefits to using a RDBMS vs. flat files on a simple Web doc system (or basic CMS)?

Question

The Project

I\'ve been asked to work on an interesting project -- what amounts to a basic Web CMS -- that uses HTML/CSS/jQuery with PHP. However, on

Answer 1

As the original poster, I wasn't signed in, so I'm following up to the answers so far in an answer (sorry if this is bad form).

• There may instances where this is on a shared host.
• Though the JSON files can technically be edited, this won't be the case. The admin interface will be robust enough to do all of the creating/editing of pages
• The size for each install will be relatively small -- 1 - 2 admins, 10-100 pages. A few lists of common items may run longer (snippets of copy for example).
• Security will be a big issue -- any other options suggestions on this specifically?

Answer 2

It's a shame you can't use CouchDB, this seems like the perfect application for it. Keep in mind that using flat-files severely constrains your architecture and, especially, scalability.

What's the best case scenario for your CMS app? It's successful and people want to use it more? If you're using flat-files it'll be harder to service and improve your system (e.g. make it more robust, and add new features for future versions) and performance will not scale well. So "success" in this case is at best short-lived, as success translates into more and more work for less and less gains in feature-set and performance.

Answer 3

What is the predicted data sizes for the CMS?

A large reason for the use of a RDMS is quick,specific access to large amounts of data. The data format might not be large, but if there is a lot of the data, then it might be better in the long run for a RDMS.

Then again, if the CSM is designed right, then switching between a flat file to RDMS should be as simple as using a different data access file.

Answer 4

While an RDBMS may be necessary for a very large CMS, a small one could run off flat files very well. A lot of CMS products out there fall down in that regard, I think, by throwing an RDBMS into the mix when there's no real need.

However, if you are using flat files, there are security issues which others have highlighted. Another issue I've come across is hosting providers using the disable_functions directive in php.ini to disable file I/O functions like fopen() and friends. If you're hosting your CMS on a box you control, you won't have this problem but if you're using a third-party provider, check first.

Answer 5

What would be cool with a simple site that was feed via JSON and jQuery is that the site wouldn't need to load on each click. Just the relevant data would change. You could then use hashes in the location bar to keep track of where you were (ex. http://localhost/#about)

The problem being if they are editing the raw JSON file they can mess it up pretty quick. I think your admin tools would have to generate the JSON files based on the input so that you can ensure nothing breaks. The admin tools would be more entailed then the site (though isn't that always the case with dynamic sites)

Answer 6

If you can't cite a specific need for relational table design, then you're good with flat files. Build as specified. The moment you can cite a specific need, let them know; upgrading isn't that hard, if you're perception is timely (that is, if you aren;t in the position of having to normalize data that should have been integrated earlier).