[fpc-pascal]Databases and FPC

[James Mills]

On Tue, May 06, 2003 at 11:02:05PM +1000, James Mills wrote:
> On Tue, May 06, 2003 at 12:10:52PM +0200, Rainer Hantsch wrote:
> > On Tue, 6 May 2003, James Mills wrote:
> > | > - How many records are assumed to be in the file?
> > | It's an IRC Services program soon to be a daemon.
> > | The number of records in the file will grow. For a small irc network,
> > | perhaps 100-200, it may grow larger in time. If a large network chooses
> > | to use my program for their large network, then the database may contain
> > | thousands of records.
> > So you must be prepared for huge data volumes from the beginning.
> 
> Tre.
> 
> > 
> > | > - What kind of file?
> > | Currently they are stored as files in a directory "./data". The files
> > | follow the structure of an INI file which I have written my own code to
> > | handle.
> > I would keep in mind that with growing complexity of a file, loading it
> > will usually also become slower.
> > 
> > | > - Sorted/unsorted file?
> > | Unsorted. Most recent record addition will always be at the bottom of
> > | the file.
> > You have to search for records? Then this is no good choice, because you
> > always have to read sequentially... Costs a lot of time.
> > 
> > | This is not very good with something that has to be stable. IRC Services for
> > | instance. If for some reason the program should die unexpectedly then the
> > | data change in memory will be lost before being written out to disk.
> > 
> > Well, when you keep all changes in memory for hours, this may be true. But
> > what about "dumping" the memory list to file periodically and (possibly) using
> > two files alternating? So even if you crash totally, one of the two files is
> > ok. --> What happens when you use i.e. MySQL as database? This can also crash
> > and has much more complexity (and therefore risks) as a flat file!
> > 
> > My experiences are: When a process DIES, this nearely always caused by poor
> > program code. And this often happens when using pointers or when not cleaning
> > up memory correctly.
> > But it is much safer to have one "database-daemon" running than having
> > multiple tasks fiddleing concurrently around in shared files!
> 
> This is true, my code us mostly 99.9% defect free. We learn a lot about
> how to engineer software at uni :) Thank you for your ideas, I'll be
> sure to come up with something. Personally I'd rather implement my own
> database as you said instead of relying on another process/task to
> handle the database.

Geeez, I can't type anymore!!! Sorry for the typos.

> 
> And as you said, if the code is flawless there should be no problem.
> 
> cheers
> James
> 
> > 
> > 
> > 
> > mfg
> > 
> >   Ing. Rainer Hantsch
> > 
> > --
> > .---------------------------------------------------------------------.
> > |      \\|//              Ing. Rainer HANTSCH  -  Hardware + Software |
> > |      (o o)              Forget Windoze! -- We focus on L-I-N-U-X... |
> > |--oOOo-(_)-oOOo------------------------------------------------------|
> > | Ing. Rainer HANTSCH |  mail: office at hantsch.co.at                   |
> > | Khunngasse 21/20    |   www: http://www.hantsch.co.at               |
> > | A-1030 Vienna       |   tel: +43-1-79885380    fax: +43-1-798853818 |
> > | ** A u s t r i a ** | handy: +43-664-9194382   UID-Nr: ATU 11134002 |
> > '---------------------------------------------------------------------'
> > 
> > _______________________________________________
> > fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal