Static pages database or files?

Hello In the CMS of the eshop i am developing the other developer for static pages stores each static page at the database.. There is a form where you add static pages on demand.But i think that instead of storing the content at the database storing the path to the file might be a better 开发者_开发问答solution... What do you think? The static content wont be always slim..

If you're going to store the path to the file in the database anyway, you might as well just store the content in the database. Either way, you're going to have to do a database lookup.

One advantage of putting everything in the database is that you can just backup the database and sleep well in the knowledge that your data is safe. If your data is scattered between the database and the filesystem, that's two things you need to backup and keep in sync. Don't underestimate the importance of sync; you don't want your DB and filesystem to go out of sync.

It's also a lot easier to keep everything organized under a primary key than it is to manage a filesystem tree cluttered with all sorts of files. If the data is binary (e.g. images), then of course you should use files. But if the data is text, it's much more convenient to use a database.

If performance is a concern, caching might be a better solution. Keep authoritative data in the DB, but temporarily cache those things that are expensive to retrieve. But of course, this depends on the size of the page, and how often the page changes. Sometimes the database can be faster than the filesystem, due to query caching and other tricks.

From a pure speed standpoint, I believe that the full DB option is going to be quicker. How much would require benchmarking, but there is no additional "hit" to the server as you'd already have the DB connection open to get the data out in the first place. Otherwise, you'd have to have the site read the file system and then use PHP to either header (redirect) to the desired page or string replace.

There is another side to this argument. Eventually, every page changes. If you have it all in the DB, it's going to be much easier to edit via WYSIWYG or other type of online editor. Sure, it's easy enough to pop open an editor on your machine and do the same with a file, but what if you opt to continue to build this and deploy it to multiple clients who --will-- want to edit their pages? If you take the time to put all in the DB now, you'll be ready for expansion. And, in the grand scheme of things, the time difference between the two is almost nothing. Plus, you can market it as a "feature" to potential buyers.

I would prefer storing the page content in files too, especially if they're heavy. But if there's an existing solution and it works... I would not change it unless it really is showing performance or other issues.

Normally, one solves this duality between (1) performance of static files and (2) data integrity of a database, by storing data in a database for integrity, and using one of the many possibilities of storing prerendered results in cache (be it flat files, APC, memcache, and the like).

On a growing and very popular project, you can't do without cache, and you can't do without data integrity, so leveraging both is the solution.

Storing a cache in a database has its advantages and disadvantages:

Advantages:

• it's easy to invalidate cache based on keys, possibly even on trigger on the database side.
• one source of content

Disadvantages:

• A terrible load on the database itself
• More difficult to scale

In most cases, with changing data all around you really want to keep load of your database, it's busy doing all kinds of modifications (inserts, updates, deletes). Storing caches in another location so memory (as the mentioned APC & memcache)) or flat files would be the way to go if your process / project doesn't depend on the latest available data (forums, blogs, reviews, etc., who cares about a couple of seconds lag). If you are making a transactional systems however (balances of credit, gaming systems, etc.), the latest and greatest if of such a major importance you will shell out for a good database which you can possibly cluster to keep a lot of servers in sync.

Keep in mind that although disk IO is very costly, often accessed & seldom changing flat files will be just as cached in memory of a system of any decent OS, if you have memory to spare on that system. Given enough load & limited resources, available hardware really comes into play, so there is no 'silver bullet' answer.