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

[Rob Scott]

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.

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.


--- 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