Re: [Bug-gnupedia] Linking to particular article?

[Hook]

Tom Chance wrote:
> > I don't think that the articles themselves should
> > necessarily be stored in a
> > database, but the "header" information could
> > usefully be kept there.  It
> > would, of course, mean that this wouldn't be stored
> > along with the body of
> > the article (think of the update issue raised
> > above).
>
> Why would you not have the articles themselves in the
> database? I mean storage space wise it makes sense to
> keep them there, in terms of accessing the article
> itself it makes sense (its faster to acces it from a
> database, rather than to get the referral from the
> database to an individual file), and it would be
> easier to update in the database (you would look up
> the article then change it, instead of looking up its
> referring point in the db then finding the article
> itself and changing that).
>
> I don't quite understand what advantages there are to
> a database and a large collection of files, over a
> simple database.

An article will often comprise a number of segments, each of which may be a
media type other than text. It's not efficient use of a database to store
large binary objects in a table - MySQL themselves recommend against it,
although they agree that the database *will* handle it. Just not
efficiently.

The same is usually true with large chunks of text.  An encyclopedia is
going to get a lot of hits, so one of the design/implementation criteria
must be performance. For example, you try hard *not* to use varchar in a
table. Use of a single one has an effect on the performance of all data in
that table. Use of TEXT in any of it's manifestations has a similar
side-effect in MySQL.

Throwing hardware at performance problems is a partial solution, true, but
designing for performance up-front is a better start.

Paul