|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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 [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.