On 8/17/2017 3:38 PM, Dan wrote:
Why do you consider this a "best practice"?
-snip-
I can see it if it's because of adding columns to a table
in the future
That's why.
-snip-
...but the tables in this application are used only in a
narrow set of programs
'Best practise' is the thing that enables change to come easier and the
outcome more predictable. Fullselect is more fragile than an explicit
column list, making change harder, and success less predictable.
It's OK to deviate from 'best practise' but it should be done with
deliberate intent, not as a rationalisation of a decision made by who
knows who, way back when. That's a lesson that was hard won for me
personally.
and it actually is necessary for them to handle any
added columns automatically.
I live with a system whose roots run deep. Lots and lots of 'load a
scratch file' > 'sort' > 'print'. Of course some of the sorts are
OPNQRYF, QRYDTA, and STRQMQRY, but they are still making copies of the
data. It has become a painful, repeated lesson that every time a copy
is made - even temporarily, just for a few minutes - the copy becomes
out of synch with the original.
It's a diversion, but imagine doing a sort/copy/INSERT INTO from a
customer master file into a copy. That takes a moment or two, and then
we do a copy/sort/INSERT INTO from a child table, say a list of
invoices. Well in the time between those two copies, someone (an EDI
system?) added a customer and an invoice. Now we have a copy of the
invoice but not a copy of the customer master. This is not theoretical,
and it's a real pattern that is only going to become more prevalent as
we move into self-provisioning (ie customers sign themselves up online).
The classic solution to this would be to ALCOBJ all of the parent/child
files in one operation, make the copies, then DLCOBJ but that is a
non-starter in a real time system.
Situations like this have started to smell like VIEWs to me, but I'm not
at all sure that's universal.
midrange.com
