OpenEuphoria

Re: data base access

• Posted by George Walters <gwalters at sc.rr.com> Aug 06, 2001
• 461 views

Rob, and Jonas, in reading your responses there is a concern I have from
both of your approaches, namely that every time a select_table() is
performed the entire file has to be read. This wouldn't  seem to support any
substantial software application. The 22 files I've mentioned for an 'order
entry' program represent 20-100Mbytes of data, when you consider 3-5k
customers, 50k inventory, 2+ stocking locations... etc. Jonas, if this is
happening on your file server just to retreive one record from several
files, I don't see how it could support multiple users. The server would be
scanning the same files front to end over and over...

So what would anyone suggest for a reasonable approach. Perhaps mysql would
be a better approach? I'm kinda at a confused point now.

Rob, I'm thinking that this type of application is beyond what you have
intended for your language to support. It seems so good on the things I've
touched so far, but appears falls short on file access, but perhaps you have
not intended for it to support this type of application. Could you comment
on this?

thanks... george




----- Original Message -----
From: "Robert Craig" <rds at RapidEuphoria.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, August 03, 2001 12:03 PM
Subject: Re: data base access


>
> George Walters writes:
> > the 'current table' issue would still be a problem in
> > a program reading from so many different data bases.
>
> EDS was designed with the idea of having
> a "current table" and a "current database".
> This was done mainly to reduce the number of arguments
> to be passed on the various database operations.
> If you are randomly accessing many different tables,
> this approach won't be as nice as one where you specify
> the database and table on every call.
>
> I doubt that performance will be an issue,
> since db_select() takes only
> a few microseconds to choose a new database, and no file
> is opened or closed. db_select_table() reads
> in 4 bytes per record from the table, but this data is likely
> cached in memory, so no disk access would be required.
> Again, we are talking microseconds.
> If you are getting input data from a user, then you will
> spend a lot longer waiting for the user to type one keystroke
> than you will spend doing a typical database update.
>
> If Jonas has alternate routines that let you
> avoid explicitly selecting a database and table,
> then you should probably use them. I don't plan to
> add routines like that to EDS. I'd rather that
> other people add extra layers of code to
> suit their needs and their taste.
>
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com
>
>
>
>
>