[fpc-pascal]Databases and FPC

[James Mills]

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.

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