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

[Hook]

Rob Scott wrote:
> What im really thinking about with holding the text in
> the db too is for the sake of mirroring/replication.
> If EVERYTHING (apart from the images of course) is
> held in the database, it is simple to do an automatic
> replication of MySQL server, with everything going at
> the same time.   However, if we use separate files
> which are referenced by the database, both the files
> and the db itself must be updated, and there is a BIG
> danger of these becoming out of sync.   If this
> happened, there would be a reference to a non existant
> document on the mirror server, because it hadnt been
> copied yet.

Existing ftp sites mirror each other, keeping gigabytes of files up to date
using a set of fairly simple perl scripts. Database mirroring is (usually)
built into the software, but still comes at a cost.
I'm still against lots of large chunks of text in a database, sorry :-)

> Although these chunks of text arent actually all that
> big, compared to what many db based websites have, and
> i think mysql could easily cope with them, especially
> with daily OPTIMIZEs/tabledefrags, it would be fine.
> I think that the benefits of everything being in the
> db WAY outweigh the downfalls BY FAR.

You can't afford to *need* to do regular table defrags, it's a large
performance hit.

Paul

> --- Hook <address@hidden> wrote: > 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
> >
> >
> > _______________________________________________
> > Bug-gnupedia mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/bug-gnupedia
>
>
> ____________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
> or your free @yahoo.ie address at http://mail.yahoo.ie
>
> _______________________________________________
> Bug-gnupedia mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-gnupedia
>