|
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. > >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact copyright@midrange.com.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.