|
> From: Fisher, Don > > I wonder about the amount of i/o performed by my approach versus yours. > Assuming I'm intelligent enough to use a procedure in a service program to > retrieve the information, would OS/400 not be smart enough to place this > frequently used data into memory? I believe I read once that it is so I > wonder what the performance impact would be, especially in an interactive > program. Would anyone notice? I can absolutely tell you that the last time I looked, caching data in arrays still beats the pants off of reading it from disk, and that the performance improvement increases the more you use the data (I got orders of magnitude increases for small tables). > I don't know. One of these days I should conduct an experiment. Please do. And if you get different results, I'll be happy to eat a little crow. > Something else to consider is how difficult would it be for an end user to > extract the data using a query tool like MS Access. Some firms have these > "power" users that make their own reports and do research while scarce > i.t. resources are focused elsewhere. A 366 character array would make > that more difficult. Not an issue for me. I don't give users direct access to production data using PC tools. First, I never let users update production data using PC tools; that to me is absolute insanity (and I doubt it would pass any Sarbanes-Oxley audits, either). Second, if they really need the data, I'll write a stored procedure. Why do this? Well, if I have to change the database layout, I can. If I have users directly accessing tables, then every database change affects all of their spreadsheets, and now IT is held hostage by MS Access. That's simply not acceptable. > I guess I'm agreeing that one does need to consider how the data is used > when normalizing. Yup. We definitely agree there. You can't just say, "Everything must be normalized. Period." Joe
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.