Re: RLA & SQL was (Re: SQL database object names longer than 10 charactersand mixedcase?)

I use a mix and match.

Have I used SQL in places where most other people would have used RLA?
Yes, but I like to think it was a special case. It was a bolt on to
existing ERP software. And the bolt on had to support two ERP releases at
once. Could I have worked around this by creating logicals that were
identical and held just the information needed by the program? Probably.
It was mostly interactive work and the key think time was much more that
what little overhead was in the SQL way back when we did this.

There are some arguments that each program should have it's own logical to
the underlying table. For example RCMORD500, RCMBIL500 for ORD500 and
BIL500 programs to access the RCM file. I do NOT subscribe to this
mentality. I feel that isn't any more maintainable than either
recompiling the programs for RLA or by using SQL to access the files
instead. And then there's the overhead of index maintenance.

Do file changes occur outside of just bad database design? Yes. Sure,
some database changes are a result of bad design "why, we'll never need
more than 3 columns for price history". But some are valid, and some were
because of limitations "way back when". Like the ERP vendor changing all
of their fields sizes, including the key to their item master file. Some
might argue that if you make all fields variable length then you'll never
run into such an issue. But I digress...

Are some database designs done because of historical misuse or ancient
mythology? Yes. There are several people who still refuse to put a key
on a PF because of something they read about on some ancient system and
how a key corruption corrupted the data. There are people who refuse to
use null fields. There are people who refuse to use RI or referential
integrity. There are people who refuse to use date fields. There are
packages out there that will allow you to put any old crap in their data
like:
- duplicate keys to the item master,
- alphabetic data in numeric fields
- parentless children
They assume that all entries are done through their applications and that
nobody ever merges two companies together or converts from another system
to theirs and has to migrate data, or import data from alternative sources
(like EDI, etc).
Many of these people, if building from scratch, would build the same crap
again. I've seen people go from RPG to PC's and do the same thing even
with different database tools.
Can some of this be blamed on, well, we did it this way because of
performance limitations back on ENIAC? Very little! That's just too
flipping long ago, and as Dieter pointed out, he got around journal hits
many moons ago.

Rob Berendt