RE: Externalize DB/IO (was What Counts as Technically Slick?)

Comments in the quotes.

>It is even better if you can get away from the file layout altogether by
>wrapping all the i/o functions for a given file inside a service program and
>then just provide procedures for specific data, like:  EVAL Status =
>CustomerStatus(CustomerID).   Now the application doesn't care how the
>status field is accessed or how it is stored or if the file layout changes.

Doing this makes it looks like Java EJB's: for every variable (or field in 
a DB-file) a seperate get- and set-method. I do not think this will improve 
performance or will contribute to any maintainance. IMHO   it is a stupid 
approach to data access.

>For perfomance, leave the service program active between procedure calls and
>have each procedure check the key supplied against the key in a cached  data
>structure in the service program from the previous call.  I've found that
>80% of your programs only need 20% (or less) of the field data and usually
>only a few fields at one time.  This gives your application complete
>insulation from DB matters.

It can go to extremes. Once a colleague of mine had to write conversion 
programmes for a lot of DB-files to fill in a new added field. Because our 
standard required to use external file servers, he wrote a conversion that 
reads sequentially the file, called the server (using an external DS), 
filled the added   field with the value supplied (with a parameter), called 
the server again for update and read the next record. To do this conversion 
he wrote an aplication that calls two programmes that opens the same file 
and that read the same record. I will spare you my comments on that, but 
those are obvious.

>If you want to load a subfile with multiple data records, just build an
>interfacing module that puts selected fields together into a
>mini-datastructure (multiple occurance) laid out according to your subfile
>needs rather than the file layout.  Since everything stays in memory, it is
>supprising fast.

In fact, the use of file servers is not a bad idea. However, keep the 
server to one DB-file and one DB-file only. In my former shop they started 
to access other files for updat as well, generating strange I/O errors or 
record locks.

Just my tuppence of ignorance.

Regards,

Carel Teijgeler.

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---