RE: Multi-member files - Big picture feedback

The biggest reason in my book to use SQL is the fact that SQL created
tables/views perform better than DDS ones.

Yes, there's a few headaches to deal with concerning copying a schema to
another library, but those can be worked around.

RPG happily uses SQL defined tables/view/indexes but you have to
remember to use the RENAME keyword to rename the record.

All my new files are defined with SQL.

HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121
  

> -----Original Message-----
> From: midrange-l-bounces@xxxxxxxxxxxx 
> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Pete Helgren
> Sent: Friday, May 26, 2006 1:15 PM
> To: Midrange Mailing List
> Subject: Multi-member files - Big picture feedback
> 
> Let's say that you have the opportunity to rewrite an RPGIII 
> based app 
> that uses multiple members in files that are poorly 
> normalized.  This is 
> your opportunity to "do it right". The DB I/O will be in RPG 
> primarily 
> and your target platform will be System i (although you may 
> have other 
> JDBC/ODBC apps that access it).  You want to keep it 
> relatively easy to 
> maintain because there will be plenty of need for backups, restores, 
> renaming of DB's either because the customer wants to set up test 
> environments or your company that provides the software occasionally 
> will do that either at a customer location at or at their own 
> location.  
> You want to be leading edge without making your life 
> miserable.  Which 
> direction do you "lean"?  To SQL/DDL tables or to 
> DDS/Physical/Logical 
> files?
> 
> I have seen issues mentioned with SQL collections.  Primarily 
> in saving 
> a "collection" and then restoring it under a different name.  Or, 
> renaming it in place.  True?
> 
> How about the relative merits of coding RPG against an SQL 
> collection vs 
> a "traditional" files based library?  Seems to me that IBM has been 
> generally discouraging the use of "traditional" files and 
> multiple members.
> 
> Is there any compelling reason to create multi-member files 
> (which would 
> rule out SQL)?  Our current customers like the multi-member approach 
> which can be used in service bureau settings (member names reflect 
> customer "clients").  We also use multiple members for denoting data 
> sets between fiscal years.  Good news and bad news in that approach. 
> Some records sets in members can reach 200 million records.  
> Some files 
> may have 10-20 members.  More, if the customer is a service 
> bureau that 
> has 20 customers with 10 years of data (200 members per file).
> 
> So, what do you all think?  Should we spend some time investigating 
> going down the SQL path or should we stick with what we have 
> done in the 
> past (cleaning up the DB a bit by normalizing it, though).
> 
> Anyone had experience with this fork in the road and what the 
> outcome was?
> 
> Thanks,
> 
> Pete Helgren
> 
> -- 
> 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.
> 
>