Re: Database I/O Modernization

On 9/15/2017 2:54 PM, Nathan Andelin wrote:

On Fri, Sep 15, 2017 at 12:38 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

I thought we were discussing your scenario.

I raised the scenario of splitting a master file into multiple files, and
the affect of that on applications.

You raised a scenario of essentially "what if there happened to be some
programs that used only a subset of fields that weren't part of the split".
How likely might that be?

CUSTOMER
NAME
ADDR1
ADDR2
CITY
STATE
ZIP
PHONE
LSTSHIPDT
LSTORDNUM
EMAIL

How many programs will use name and address but not last ship date, or
last order number? How about email, but not address? It's my personal
experience that virtually no program uses all of the columns in any
master file, so yeah, it's quite likely that there are lots and lots of
programs which don't use the affected columns.

I think there is a good case to be made for externalizing SQL into views.
Less of a case for hard-coding SQL into HLL interfaces. And even less of a
case when fetching rows from SQL result sets into data structures - if your
main point is "decoupling".

Given: SELECT NAME, ADDR1, ADDR2, CITY, STATE, ZIP

There's little difference in coupling between
FETCH INTO :AddressDS

and

FETCH INTO :name, :address1, :address2, :city, :state, :zip

Somewhere inside the program we will have to declare the individual
variables to accept the I/O. Whether these are subsequently grouped
together into a data structure does not seem to affect the coupling one
way or the other.

If you do that in order to streamline code, or for programmer productivity
purposes, that would be another matter. People should have the option of
weighing the trade-offs.

Of course; have I argued otherwise? My only substantive comments have been:
1) I would not use this middle-layer to do I/O at all, no matter how it
was implemented
2) I would use SQL instead
3) It is the tight coupling of RLA which makes changing tables so burdensome
4) SQL is more loosely coupled than RLA