Flat File Vs. Cms Which is More Efficient?

[rpgsearcherz 5]

I decided to post this here because the entire forum is devoted to web developers -- so I felt this is the best place.So my question is as to which is more efficient between a CMS and a flat-file system.To give you a little more information, here's how I've been looking at it:1) I plan to have very minimal graphics. These will likely be hosted on the site itself2) I plan to have videos but they will be hosted elsewhere3) As I go along I plan to expand the site and I am seeing it as getting to where at some point it's thousands of pages long (or at least, that's the goal)Some of the things I am worried about are:1) Which would use more bandwidth? This includes both "BPS" and monthly limits (I'm thinking the CMS because it has to keep searching a database)2) Which would be more CPU intensive? (I'm pretty sure this one would be the CMS as it runs off a database)3) CMS's, due to the nature of using databases, have a maximum limit of users per time in terms of access. Does HTML have the same deal?Now when looking at the "ease" of both -- I'm pretty well versed in both CMS and flat-file systems. I am perfectly fine with either one which is why this is soo important. If things go as I plan, over time the site will grow greatly. I've already organized a data structure for the site (in terms of how to store the files/organize them) that would work perfect. I just want to make sure I'm making the right choice and that I'm correct in assuming flat-file would be better.I'm also interested in knowing if flat-file would be the most efficient for smaller sites as well (such as 5-6 page ones).Just to reiterate, I'm not asking which one is "easier," or anything like that. My question is solely based on how well they perform in terms of maximum users at once, bandwidth (BPS/monthly usage) and CPU usage.Any input would be much appreciated.Thanks guys.

[rvalkass 5]

1) Which would use more bandwidth? This includes both "BPS" and monthly limits (I'm thinking the CMS because it has to keep searching a database)

Accessing the database doesn't actually count as using any bandwidth as far as I know, as you're accessing a server within Xisto's network, so there isn't any real bandwidth cost. The pages you'd generate would be the same from a database-driven site and a flat-file site, so they would use identical bandwidth to your end users.

2) Which would be more CPU intensive? (I'm pretty sure this one would be the CMS as it runs off a database)

It very much depends what you're doing. Remember that a database is designed to be sorted, queried and searched, and is therefore optimised for it. It also runs on a separate server, again specifically for that purpose. Flat files were not designed to be treated as databases, and the functions to "query" them are very limited, and usually have to be written from scratch. These functions will therefore likely use far more CPU power than performing the equivalent task on a database.

3) CMS's, due to the nature of using databases, have a maximum limit of users per time in terms of access. Does HTML have the same deal?

CMSs have no maximum limit to the number of concurrent users. Even if the database has a limit to the number of concurrent users, it is always being accessed by the same user - the one you set in the configuration for the CMS. Apache servers have a configuration option allowing the admin to limit the number of concurrent users accessing a server. That would affect any website (whether database-driven or flat-file based) as it limits the number of users who can view any HTML output. There's not really anything you can do about that limit - it's there to stop server overloads and DoS attacks.

Now when looking at the "ease" of both -- I'm pretty well versed in both CMS and flat-file systems. I am perfectly fine with either one which is why this is soo important. If things go as I plan, over time the site will grow greatly. I've already organized a data structure for the site (in terms of how to store the files/organize them) that would work perfect. I just want to make sure I'm making the right choice and that I'm correct in assuming flat-file would be better.

I would disagree that flat-files would be better. It does depend on the exact type of data, and what you intend to do with it, but a database just provides so much more flexibility to you. It would also be faster and have less impact on the server. When your site is small flat files may be fine and fast enough, but when you start getting thousands of them, a full text search could take minutes!

I'm also interested in knowing if flat-file would be the most efficient for smaller sites as well (such as 5-6 page ones).

For 5-6 pages flat files would be fine. They're simple, but they just don't scale well. Many small sites use pure HTML pages with no PHP or database back end. They're fine, but they are small sites, and not very flexible. When you want to provide any facility beyond displaying pages in a basic manner (searching, sorting, querying, organising, or further site features such as logins, email newsletters, etc.) you can't really with pure HTML, and you have to add databases and scripting anyway.

[truefusion 3]

A CMS that works with a database would be more CPU intensive, since you are not only running the parser for the language the CMS is written in, but that very same parser would be communicating with an external program. However, this does not mean that it will affect performance significantly. Only when you are trying to make a lot of calls to the database should performance be considered. This is why popular CMSs have their own cache system. Cache helps make big, popular websites that make use of a database scale better. Cache is just flat files with their own identifier (usually as their file name) to later be retrieved by the script. This alone should tell you that flat files have some domninance over a database when it comes to performance. However, a database is much better suited for retrieving arbitrary information and for storing personal data. A properly built CMS that makes use of a database would be able to tell when a query should be cached or not.Whether or not you should make use of a CMS that uses a database depends on your site and what you want to provide. Are you planning on having people comment on your articles (if any)? Are you going to "post and forget"? Would you like people to search your website? What do you mean by "expand": content size or what it offers to users and therefore attracts users? Might as well choose a CMS that makes use of a database. There's no loss in going with one if you decide to later stop working on the site. At least then you won't have to set your site up again when migrating to another CMS.

[rpgsearcherz 5]

Thanks a lot for the insight, guys. Based on all of the reading from you two it seems the concurrent answer is "CMS is no worse than flat-file but can even be more efficient."But rvalkass brought up something I'm a little confused about -- the database not using bandwidth on the Xisto network. This would mean that the CMS would use less bandwidth than flat-file (since the CMS stores all information in the database -- at least text)? Or did you mean the searching and pulling of information wouldn't count as bandwidth but the actual serving of information would?Thanks again guys.

[truefusion 3]

But rvalkass brought up something I'm a little confused about -- the database not using bandwidth on the Xisto network. This would mean that the CMS would use less bandwidth than flat-file (since the CMS stores all information in the database -- at least text)? Or did you mean the searching and pulling of information wouldn't count as bandwidth but the actual serving of information would?

Bandwidth is any data transferred from the server to the user. A program communicating with another program on the same system does not affect bandwidth. Consider a dynamic page and a static page that contains the same information as the final product of the dynamic page (e.g. cached version of the dynamic page). One will always query the database for the information while the other page doesn't have to because it already has all of the information stored. Both pages are the same size when the dynamic page is done being parsed and generated (let's say 12kbs per page), and so only 12kbs of bandwidth is wasted when you access either page. If you access both pages at the same time, 24kbs of bandwidth is used.

[rpgsearcherz 5]

Bandwidth is any data transferred from the server to the user. A program communicating with another program on the same system does not affect bandwidth. Consider a dynamic page and a static page that contains the same information as the final product of the dynamic page (e.g. cached version of the dynamic page). One will always query the database for the information while the other page doesn't have to because it already has all of the information stored. Both pages are the same size when the dynamic page is done being parsed and generated (let's say 12kbs per page), and so only 12kbs of bandwidth is wasted when you access either page. If you access both pages at the same time, 24kbs of bandwidth is used.

Very interesting -- didn't know that's how it works.

I've noticed on some hosts that if you use a CMS it will time out a lot/lag but with flat-file systems there is absolutely no issue. This is where my concern with using CMS's came from.

I'm not quite sure exactly which direction I'll be taking the site(s) but there will be two or three of them, hopefully linked together in one way or another. Pretty much all I've decided so far is the overview of them and the structure -- not the exact details.

[Little Asterisk 1]

Depending on your "geekyness" and knowledge of PHP and similar programming languages, I suggest you not to pick neither a database-driven CMS nor a flat-file system, but Stacey ( that's staceyapp.com ).

 

It's relatively easy to use, very, very easy to setup (you only need to upload files to your server), and it's extremely lightweight. You don't have a regular back-end (like Wordpress, for instance, does), but you simply upload folders to your /content folder of your website.

 

In the /content folder, you keep both your pages and blog posts, which you can sort by number (the higher number being first on the list). For instance, at the beginning you receive this layout:

 

2. contact-me

3. about

4. projects

1. project-name-10

2. project-name-9

etc., these are the blog posts

feed

index

sitemap

I've only listed the subfolders of the "4. projects" folder, but you get the logic. A sample blog post looks like this:

 

title: The Test Project 10

-

date: 2009, Jun–

-

content:

Blog post content goes here, you get the deal, I think.

I haven't yet researched everything Stacey (the app, not my friend ) can do, but from the looks of it, Stacey is a very powerful tool. If you know PHP, you can even extend it easily because it isn't put into too many files.

 

Just reading this now, made me realise I'm actually starting to like *her*.

And, unfortunately, no one's paying me for advertising *her*.

Edited July 25, 2010 by Little Asterisk (see edit history)

[rpgsearcherz 5]

Depending on your "geekyness" and knowledge of PHP and similar programming languages, I suggest you not to pick neither a database-driven CMS nor a flat-file system, but Stacey ( that's staceyapp.com ).

 

It's relatively easy to use, very, very easy to setup (you only need to upload files to your server), and it's extremely lightweight. You don't have a regular back-end (like Wordpress, for instance, does), but you simply upload folders to your /content folder of your website.

 

In the /content folder, you keep both your pages and blog posts, which you can sort by number (the higher number being first on the list). For instance, at the beginning you receive this layout:

 

2. contact-me

3. about

4. projects

1. project-name-10

2. project-name-9

etc., these are the blog posts

feed

index

sitemap

I've only listed the subfolders of the "4. projects" folder, but you get the logic. A sample blog post looks like this:

 

title: The Test Project 10

-

date: 2009, Jun

-

content:

Blog post content goes here, you get the deal, I think.

I haven't yet researched everything Stacey (the app, not my friend ) can do, but from the looks of it, Stacey is a very powerful tool. If you know PHP, you can even extend it easily because it isn't put into too many files.

 

Just reading this now, made me realise I'm actually starting to like *her*.

And, unfortunately, no one's paying me for advertising *her*.

 

Very good, informative post. I never thought of using a system like that before. I think there's other good ones as well and your post is causing me to go searching for them. Pretty much what it is is a "file management system," much like a lot of addons for CMS's can do (such as, there's one on Joomla where you have a music file directory and when you add new music to it, it automatically updates your site with a listing of the new songs that can be downloaded).

 

I'll have to analyze the systems some more to see how well I can adapt them to what I'm going for though.

[truefusion 3]

Depending on your "geekyness" and knowledge of PHP and similar programming languages, I suggest you not to pick neither a database-driven CMS nor a flat-file system, but Stacey ( that's staceyapp.com ).
It's relatively easy to use, very, very easy to setup (you only need to upload files to your server), and it's extremely lightweight. You don't have a regular back-end (like Wordpress, for instance, does), but you simply upload folders to your /content folder of your website.

Interesting, "Stacey" functions a lot like my CMS. I've been looking for ways to improve my system, and "Stacey" seems like it has some interesting features that would be good to implement into my CMS.

[rpgsearcherz 5]

Interesting, "Stacey" functions a lot like my CMS. I've been looking for ways to improve my system, and "Stacey" seems like it has some interesting features that would be good to implement into my CMS.

I think when researching for like-programs the thing to look for is "File Management System." As far as I know that's the official term for it, since you're not really making a website out of it, per-se, just setting up a way for each document to be shared. You may be able to pull other ideas from looking into those as well.

When I finish with my CSS learning I plan to head into PHP. I may just adapt my own CMS to my site. Based on my understanding they really aren't *too* hard to make, since more or less it's just partitioning off parts of the site using CSS and then using PHP to pull and store data. Since it'll be for a normal website I won't need a lot of "special" features either (like what you would find in the Joomla backend, forums, etc.) and instead will just need it to store the HTML code and pull it.

One question for you though, truefusion. Since you've made a CMS I'm hoping you could shed some light on this. When you format a page using HTML and put it into a database, do you have it just copy the entire HTML code into it and pull the code? Like would it be the same as going into phpmyadmin and just pasting the HTML from your page into it?

Wondering about that because I still don't quite get how SQL stores information, and it seems like it would be a LOT to store an entire page in one SQL box.

[truefusion 3]

One question for you though, truefusion. Since you've made a CMS I'm hoping you could shed some light on this. When you format a page using HTML and put it into a database, do you have it just copy the entire HTML code into it and pull the code? Like would it be the same as going into phpmyadmin and just pasting the HTML from your page into it?
Wondering about that because I still don't quite get how SQL stores information, and it seems like it would be a LOT to store an entire page in one SQL box.

A database can store many kinds of "data types." This touches on more primitive parts of programming, but i won't get into that thoroughly. The HTML code is human-readable, and a "string" (a data type that can store text) can contain the entire HTML code without making it into "jumbled text" (binary format). Therefore, when you pull it out of the database, it is as if you opened an HTML file in a text editor.

[mahesh2k 0]

Staceyapp looks cool. I wish i can use similar system for the blogging with little bit more control in admin dashboard. I don't think staceyapp is good for blogging. I'm trying to find the less complex CMS for blogging & static sites. Sometimes wordpress, joomla etc too much for learning curve and work. Thanks for posting about staceyapp,i'm going to take a look at it. In between is there any good flat file blogging platform available ?

[Little Asterisk 1]

Staceyapp looks cool. I wish i can use similar system for the blogging with little bit more control in admin dashboard. I don't think staceyapp is good for blogging. I'm trying to find the less complex CMS for blogging & static sites. Sometimes wordpress, joomla etc too much for learning curve and work. Thanks for posting about staceyapp,i'm going to take a look at it. In between is there any good flat file blogging platform available ?

Hmmm, if you're looking for a flat-file platform probably the easiest way would be to make it yourself (no, really), because I don't know about that many of them. Most use databases for pulling data from the server (duh, data-base ). But I think it shouldn't come to that since Stacey is pretty powerful as a CMS. Just look at what David DeSandro did on his blog (http://forums.xisto.com/no_longer_exists/ ), and I think you'll find out for sure. There's even a post "dedicated" to Stacey (Going steady with Stacey, http://forums.xisto.com/no_longer_exists/ ). As for other systems (that may use a database), Smashing Magazine has recently tweeted about a CMS called zotonic (http://zotonic.com/ ), which seems like an interesting way to blog. It's made in a language called "Erlang" (never heard of it until now), and the back-end reminds me of Wordpress a lot (just watch the video and look at some of the screenshots in the gallery - http://zotonic.com/gallery/ ). I personally wouldn't use it since I wouldn't feel comfortable with using a language I don't know (Erlang), but someone maybe knows it or simply doesn't want to mess with the back-end code anyway. Its plus sides are that they claim it's very fast. Anyway, for anyone who wants to explore the CMS world a bit more, I suggest looking at this blog post over on Vivalogo: http://www.vivalogo.com/vl-resources/free-lightweight-simple-cms.htm Lightweight CMS systems, I haven't looked through all of them, but I suppose at least some of these forty use File Management.

 

[Little Asterisk 1]

Hate to reply to my own post, but just now I've found a very-very-very lightweight CMS/File Management System, which can only be downloaded via Github (I think it's git.com, but if not just Google it). The name is Toto (http://cloudhead.io/
toto ), and it's "The tiniest blogging engine in OZ". Since it uses no database (as I understand, I haven't tried it yet), you can't have comments on your site, but that's easily handled with other comment-only systems like Disqus ( https://disqus.com/ ) and similar.Warning: Command line work needed.