RE: Externalize DB/IO

["York, Albert" <albert.york@xxxxxxxxxxxxxx>]

I think this has gone far astray of my original point. I am not opposed to
moving data base processing to a separate process. In fact, I published an
article recently in Midrange computing ("Breaking up is not hard to  do -
moving your interactive processes to batch") in which I describe a process
for using server programs running in batch to process database requests.
Depending on how many users perform the same function, you can gain
significant performance improvements. 

My original point was that the "server programs" that we changed did nothing
but record I/O, which could have been handled just as easily in the calling
program.

Albert York     


        -----Original Message-----
        From:   NSmith@lincare.com [SMTP:NSmith@lincare.com]
        Sent:   Tuesday, April 10, 2001 2:12 PM
        To:     MIDRANGE-L@midrange.com
        Subject:        RE: Externalize DB/IO

        The trick is to not tie it to a datastucture defined by a DB file.
Either
        make it more specific, like GetCustName(Custno) or pass a
datastructure that
        is not tied to the file.  It can still contain most of the oft-used
fields,
        but it would allow you to change the file(s) without touching the
programs
        that use the procedures.  Of course, when you change the fields in
the
        datastructure, you would then have to change the calling programs.
This
        separation also would allow you to do things like combining the data
from
        several files into one datastructure that your procedures use.  i.e.
the
        datastructure could be in essence a flat-file format saving the
program from
        having to bring in all the related relational tables.  It can really
save
        tremendous amounts of complexity in the application program.  

        When you need customer data, what's wrong with getting, in one big
        structure, everything you have stored about that customer, without
regard to
        all the different files the data is actually stored in?  Let a
middle-ware
        procedure assemble it all for you. Then you change your procedure
from
        GetCustMastRecord to GetCustomerData. Then, once you've written one,
it's
        very easy to derive others, like GetActiveCustData which just calls
        GetCustData and loads only the active records.  About as close as we
can get
        to Object-like programming.  

        Programs need data, not files.

        > -----Original Message-----
        > From: Gwecnal@aol.com [SMTP:Gwecnal@aol.com]
        > Sent: Tuesday, April 10, 2001 12:51 PM
        > To:   MIDRANGE-L@midrange.com
        > Subject:      RE: Externalize DB/IO
        > 
        > If you externalize all db/io and provide a bunch of funcitions
like
        > GetCustMastRecord
        > UpdateCustMastRecord
        > etc
        > and each of them passes a key and a data structure to hold the
        > data, don't you still have to hunt down and recompile all the
        > programs when the data structure changes?  How have you
        > helped yourself? I'm not fussing, I really want to know.
        > +---
        > | 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
        > +---


        
****************************************************************************
****************************************************************************
****************************************************
        This message originates from Lincare Holdings Inc. It contains
information which maybe confidential or privileged and is intended only for
the individual or entity named above.
        It is prohibited for anyone else to disclose, copy, distribute or
use the contents of this message. 
        All personal messages express views solely of the sender, which are
not to be attributed to Lincare Holdings Inc., and may not be copied or
distributed without this disclaimer. 
        If you received this message in error, please notify us immediately
at MailAdmin@lincare.com or (800) 284-2006.
        
****************************************************************************
****************************************************************************
****************************************************
        +---
        | 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
        +---
+---
| 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
+---