By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,640 Members | 2,597 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,640 IT Pros & Developers. It's quick & easy.

when to store content in a database table?

P: n/a
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
Jul 17 '05 #1
Share this Question
Share on Google+
1 Reply


P: n/a
Roderik <ng@nl100.cjb.net> wrote:
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


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


Jul 17 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.