Re: Normalization was Left AS/400 and Returned -- MIDRANGE-L

I would think getter subprocedures would be more modern.
 :)  Once overloading is available in ILE, it would be
great.

Brad


On Tue, 3 May 2005 15:28:07 -0400
 MWalter@xxxxxxxxxxxxxxx wrote:
> So, what you're saying Michael is that native I/O is a 30
> year old
> technique, and is akin to RPG II? Whereas, if you want to
> be 'modern' you
> must use SQL or Join Logicals? Hmm. Let me think about
> that for a while.
> 
> Thanks,
> 
> Mark
> 
> Mark D. Walter
> Senior Programmer/Analyst
> CCX, Inc.
> mwalter@xxxxxxxxxx
> http://www.ccxinc.com
> 
> 
>
                                                          
>                 
>              michael@ryantechn
>                                             
>              ology.com
>                                                     
>              Sent by:
>                                                   To 
>              midrange-l-bounce         Midrange Systems
> Technical          
>              s@xxxxxxxxxxxx            Discussion
>                          
>
                                       <midrange-l@xxxxxxxxxxxx>
>           
>
                                                          
>              cc 
>              05/03/2005 03:08
>                                              
>              PM
>
                                                   Subject
> 
>                                        RE: Normalization
> was Left AS/400   
>                                        and Returned
>                        
>              Please respond to
>                                             
>              Midrange Systems
>                                              
>                  Technical
>                                                 
>                 Discussion
>                                                 
>              <midrange-l@midra
>                                             
>                  nge.com>
>                                                  
>
                                                          
>                 
>
                                                          
>                 
> 
> 
> 
> 
> Of course, a lot of RPG programmers don't use join
> logicals. Instead,
> they provide their own indexed file navigation by getting
> a value from
> one file, using that value to chain to another file,
> getting value from
> that file, chaining to another file...and on and on.
> There's a divide in
> AS/400-land...those that can/will use SQL or join
> logicals and want a
> normalized database, and those who have a series of
> indexed files and
> do their own navigation. Basically, if a programmer wants
> to use more
> modern techniques, the iSeries can support them. And of
> course, if a
> programmer still wants to code in RPG/II, they can. The
> ability to use
> 30 year old techniques is a 'feature' on the iSeries.
> 
> 
> > -------- Original Message --------
> > Subject: Re:  Normalization was Left AS/400 and
> Returned
> > From: rob@xxxxxxxxx
> > Date: Tue, May 03, 2005 2:55 pm
> > To: Midrange Systems Technical Discussion
> <midrange-l@xxxxxxxxxxxx>
> >
> > I agree on the multi-format and join logical files.
>  Or, SQL's views.
> And
> > highly recommend them for programming, and, most
> especially, for common
> > links the users use in Queries instead of having them
> join multiple files
> 
> > together.
> >
> > However, he might be right about the performance issue.
>  For example,
> > which would access faster:
> > 1 - A key over customer number and part number in a
> de-normalized
> > order/line file.
> > 2 - A join logical that joins the order/header file
> with the order/line
> > file so that you can see the customer number from the
> order header file
> at
> > the same time you see the part number of the order line
> file.  And, keep
> > in mind, that a join logical file does not allow keys
> from more than one
> > file, even though I suspect every new release of OS/400
> has formed yet
> > another DCR requesting this feature.  This might be
> possible with an
> index
> > on a view in SQL but I don't think that's allowed
> either.  I know you can
> 
> > get the data this way in a normalized database via SQL
> but it's going to
> > do some work under the covers and performance may
> suffer.
> >
> > Rob Berendt
> > --
> > Group Dekko Services, LLC
> > Dept 01.073
> > PO Box 2000
> > Dock 108
> > 6928N 400E
> > Kendallville, IN 46755
> > http://www.dekko.com
> >
> >
> >
> >
> >
> > "Bill Meecham" <bmeecham@xxxxxxxxxxxxxxxxxxxx>
> > Sent by: midrange-l-bounces@xxxxxxxxxxxx
> > 05/03/2005 01:33 PM
> > Please respond to
> > Midrange Systems Technical Discussion
> <midrange-l@xxxxxxxxxxxx>
> >
> >
> > To
> > "Midrange Systems Technical Discussion"
> <midrange-l@xxxxxxxxxxxx>
> > cc
> >
> > Subject
> > Re: Left AS/400 and Returned
> >
> >
> >
> >
> >
> >
> > That's not necessarily true since multi-format and join
> logical files can
> 
> > be created and created much easier when the database is
> normalized.  The
> > reason shops don't normalize is more likely because
> it's difficult to
> > master and there is little perceived benefit.
>  Borrowing from another
> > thread, that's a large part of what case tools help
> with....normalization
> 
> > and 'virtualization' of fields.
> >   ----- Original Message -----
> >   From: michael@xxxxxxxxxxxxxxxxxx
> >   To: Midrange Systems Technical Discussion
> >   Sent: Tuesday, May 03, 2005 2:25 PM
> >   Subject: RE: Left AS/400 and Returned
> >
> >
> >   The reason that most vendors and shops don't have
> normalized databases
> >   is because most vendors and shops don't use the data
> store on the
> >   iSeries as a database - it's used as a system of
> indexed files.
> >   Normalization in that scenario can hurt performance,
> because the
> >   program would need to chain to several files to
> gather the information
> >   needed to present to the user. There's no doubt that
> normalization is a
> >   good thing for a database (at least 3NF), but
> normalization for indexed
> >   files isn't as important or desired.
> >
> > --
> > This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> > list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> archives
> > at http://archive.midrange.com/midrange-l.
> >
> >
> > --
> > This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing
> list
> > To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> > To subscribe, unsubscribe, or change list options,
> > visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> > or email: MIDRANGE-L-request@xxxxxxxxxxxx
> > Before posting, please take a moment to review the
> archives
> > at http://archive.midrange.com/midrange-l.
> 
> --
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 
> 
> 
> -- 
> This is the Midrange Systems Technical Discussion
> (MIDRANGE-L) mailing list
> To post a message email: MIDRANGE-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit:
> http://lists.midrange.com/mailman/listinfo/midrange-l
> or email: MIDRANGE-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the
> archives
> at http://archive.midrange.com/midrange-l.
> 

Bradley V. Stone
BVS.Tools
www.bvstools.com