> 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 thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.