[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gne]API

From: Tom Chance
Subject: Re: [Bug-gne]API
Date: Thu, 28 Jun 2001 16:22:05 +0100

>> Well the other solution was to put all the bodies into text files and have
>> extra field in the database to link to that text file - in effect using
>the database
>> as a search index. But opinion has been a bit divided as to whether or not
>> putting the body in the db will slow down or lock up the db.
>You're right, it is the viable alternative. My experience with databases
>suggests that putting large blocks of data into a single row always gives a
>performance hit. BTW, if you're considering MySQL's full text indexing, be
>aware that it can be *enormously* slow.
>Database design is a complex field, more so if you want to build something
>which will give good performance as the number of concurrent users climbs.
>The Hooker

Well at the moment it will only take a couples of lines of code to change
between either system, so it's not a disaster if we find one is not working as
well as we had hoped. So if we find that having the body in the db makes
it much too slow we can just export all of the bodies into text files which
are named according to the Article ID (AID), which would be easy to do.
We could then just delete the "body" field from the db, and change the add
and view scripts to pull the body from a text file.

So then the only things in the db will be the basic info for an article:
aid, datesub, author, lang, title, synopsis, seealso

And any searches will only check through the "title" and "synopsis" fields
(whilst we will probably allow people to specify an author/lang) which shouldn't
be too slow. Keep in mind that for at least a year the actual server load here 
going to be fairly small, and that even when GNE becomes quite popular there
shouldn't be more than a few articles being viewed at any one time. It's not 
we'll have articles flooding in and people checking back to read the latest 
Not that I'm saying we can be complacent and lazy, but we don't need to worry
*too* much at the moment about how we'll do things.

Really we should just concentrate on getting the basic system up and running
with GNU, attracting people to GNE to start adding articles (and therefore 
us ample time to test the system), and working on things like an API (if we want
one) and mirroring systems etc. The whole system at the momentis flexible and
scaleable. At the beginning of the project, RMS warned us not to get too bogged
down in the tools and to get a working system up fast, and thats what we should
be doing for now.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]