Re: Database I/O Modernization

On Thu, Sep 14, 2017 at 3:31 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

If I need to refactor CUSTOMERS, I will only need to touch this
particular program if I change the referenced columns.

I'm working on a proof-of-concept application for a legacy system that
supports carriers in the long-haul trucking industry. One of the master
files in the database contains something like 250 fields pertaining to
"shipments".

It appears that shipment data could have been more correctly aligned with
business entities, operations, activities, and transactions by perhaps
dividing the data into more files:

Shipments.
Shipment parties (shippers, receivers, 3rd-parties).
Shipment activities (pickup, delivery, transfers to 3rd-party carriers,
driver switch, accident recovery).
Shipment tariff data.
Shipment pricing data.
Shipment billing data.
Shipment financial transactions.

I wonder how many hours may have been spent in lost productivity, in the
development of exception handling and work-a rounds, due to an original
database design?

Now that the original file is referenced in hundreds, or perhaps thousands
of programs, the cost of changing the design would probably be very high.
Would it have helped if SQL had been used instead of "F" specs?