Logical File or OPNQRYF or any other way ? - Legacy

[William Washington III <w.washington3@xxxxxxxxxxxxx>]

Yes, I recognized that possibility immediately.  That's why I mentioned that
one cannot go to extremes when using it (as I understand the technique.)

I believe that a properly-designed database file should have minimal views with
differing record formats.  We've all seen files related with the same key, but
different info in the files.  This is because of the "functional independence"
of the data.  If the data is functionally dependent, the related information
would be in the same file.  If they are functionally independent, the data
would be split over several files.

An example is an employee file (table), keyed by employee ID.  There may be two
tables keyed by employee id because the base information (name, address, start
date) information by employee is functionally independent of the H/R
disciplinary information (discipline flag,  disposition, etc.).

SO my conclusion that if the "base tables" are designed properly, I can use a
view over the same files (using all fields in the file) and all will be good. 
No propagation of different views.

But your basic idea that the views must be controlled, lest we experience the
problems mentioned, is very well-taken.  Up-front design is everything.

Thoughts?

William

> date: Wed, 9 Mar 2005 07:14:20 -0800 (PST)
> from: Eduard Sluis <eduard@xxxxxxxxxxxxxxxxxxxxxxx>
> subject: RE: Logical File or OPNQRYF or any other way ? - Legacy
> 
> Please, do not go on that path!!!!
> You will create a magnitude of different logicals with all kinds of nasty
> record-formats not representing all the fields in the PF record-format.
> You get your self in serious problems determining what logical/record-format
> to use when you have to create a new function over the Db....Yeah, the
> accesspath exist. Noooo, the fields needed are not in this record-format!!!
> What to do???? Create a other LF??
> I've seen laaaaarge systems with numerous logicals with exact the same
> access-pathbut different records-formats because they had to decide
> every-time 'for the sake of not having to recompile and to distribut half of
> the application running in more than 50 countries' to create a new logical on
> the same path but with again an different record-format.
> There system would have been a lot nicer/smaller/faster when they had kept
> them self to the 'First lesson of databasedesign'. One PF has One
> record-format! Every LF uses this record-format!
> When one PF got more than 10 LF's......You have to determine if your Db
> design is still correct!
>  
> Eduard.
> 
> 
> William Washington III <w.washington3@xxxxxxxxxxxxx> wrote:
> Hey! Now THAT is kewl! Seriously! And it makes perfect sense, because the
> view has all of the info that particular program needs. Another program would
> use a different view. I see no need to ever change a particular view, unless,
> once again, someone went to extremes with creating them.
> 
> I'll put that info to use immediately! Thanks, Chris.
> 
> William
> 
> 
> > date: Tue, 8 Mar 2005 15:19:07 -0800 
> > from: Chris Bipes 
> > subject: RE: Logical File or OPNQRYF or any other way ? - Legacy
> > 
> > Actually if you create views to use with your RPG program that do not share
> > the view of the PF, you can add or move fields in the PF and not effect any
> > RPG programs using the other views. Now if you remove a field used by SQL
> > or RPG you will have problems until you update your programs not to use
> that
> > field. It will also cause problems with your defined views. Think of a LF
> > that has it's own record format, not using the PF record format as a view.
> > 
> > Now how does that differ from imbedded SQL except in flexibility of
> creating
> > the view on the fly.
> > 
> > Chris Bipes
> > 
> > 
> > -----Original Message-----
> > If I make a change to the database, yes, I will have to modify (typically,
> > recompile) my RPG programs. So what? That's part of the process. The fact
> > that the database is bound to the program gives RPG its well-deserved
> > reputation for random-access performance. That is the design tradeoff for a
> > business machine. If the data layouts are changing all the time, well, what
> > kind of model is the business operation on?
> > 
> >