when to store content in a database table?

[Roderik]

Hi,

When developing a website in general when should I choose to put
content in a database. For menu options, settings, and listings like
products it seems to be clear for me to put them in. But the main
content (article for example) should I put that in a page or in the
database. More in general, when would it benefit to use a database and
when not. Does anyone know a good tutorial or do you have advice
concerning this.

Kind regards,

Roderik

[thumb_42@yahoo.com]

Re: when to store content in a database table?

Roderik <ng@nl100.cjb.n et> wrote:[color=blue]
> Hi,
>
> When developing a website in general when should I choose to put
> content in a database. For menu options, settings, and listings like
> products it seems to be clear for me to put them in. But the main
> content (article for example) should I put that in a page or in the
> database. More in general, when would it benefit to use a database and
> when not. Does anyone know a good tutorial or do you have advice
> concerning this.
>
> Kind regards,
>
> Roderik[/color]

That really depends on a lot of factors, such as networked filesystems,
access time, type of database, access points, etc..

In general, I avoid using a database when a file would do. This is
because the filesystem is generally faster than a database. Often
performance can increase if you use a DBM (like gdbm or berkeley)
instead of a database. But... this type of optimization can be more
problematic than it's worth in a lot of other cases. (It's good at
caching words to numeric ID's, things that map 1-1 and don't change, but
lousy if mappings change often.)

If the information changes a lot, or needs more keys than just the
filename and if you're using a database anyway.. then a database makes
sense. (even then, I'd recommend storing larger chunks as files due
to the hassles and typical overhead of storing blobs)

If you've got to work across multiple hosts, a database may make sense
because it's easier to synchronize. (especially for session data) but
not for everything.

For situations where articles change, or need multiple segments,
consider storing the article as an XML document and parsing it. (storing
a cached copy of the HTML on the filesystem)

Depending on how your XML article is formatted, you can index portions of
the article (such as topic, author, date, etc..) in a database for
searching, then storing only the filename in the database, using that
for retrieval. With rsync and a server farm, this can work out good.
(and also is nice to take some of the work off the database)

The other thing to keep in mind is the scale of the database. If you had
a dozen web servers serving content, but only 1 server running a
database which held all content, that 1 database server will be
overworked. Using files in this case would probably make more sense.

Because of all these factors (and many more...) an accurate guide would
be very difficult to write, and ultimately be more confusing than it'd
be worth.

Jamie