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

[Hook]

Tom Chance wrote:
> > 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.
>
> You wouldn't store things like pictures and movies IN
> the mySQL databse! But it would be more efficient to
> store text in a database, rather than as many XML
> files. Especially if you OPTIMIZE it often.
>
> >
> > 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.
> Varchars are better to keep to a minimun, but even so
> a database with many varchars and text fields would
> still be more efficient than a large XML filesystem.
>
>
> > Throwing hardware at performance problems is a
> > partial solution, true, but
> > designing for performance up-front is a better
> > start.
> Databasing is performance up-front. Many files would
> need better hardware to get comparable speeds.

Not entirely I'm afraid.  If that was really true, then Usenet would use a
database rather than either lots of small files (and in the case of net news
it's the huge number of tiny files which causes trouble), and it doesn't.
The closest is diabolo which uses a small number of enormous files with
comprehensive indexing.

I'd lean towards letting UNIX handle the articles (XML, text, word documents
or whatever), and have a database handle the meta data - author, title,
keywords etc.  UNIX after all is pretty good with text files.

Paul