How practical this change would be, if it represented a large, existing data base, would be a separate
question. If this is at the initial design, however, this is an easy change to make.
Boundary considerations. In Java, we are done because Java will order the three entities such that the
least amount of space is wasted. In C and C++, it might be possible to lay out the storage entities such
that the compiler will not introduce padding between elements. In this particular example, the order given
above would work out well.
Which is more important?
Reading the above superficially, one would expect the currency table improvement to matter most. There
was a reduction from an N squared to an 2 times N relationship. However, this cannot be right. In fact,
the number of countries is not “N” for this problem. “N” is the number of outstanding orders, a number
that is likely in a practical system to be much larger than the number of countries. More critically, the
number of countries is essentially fixed. Yes, the number of countries in the world change from time to
time. But, of course, this is not the same degree of change as order records in an order entry system. In
fact, the currency table is part of the Order(1) storage. The choice between 2 times N and N squared
should be based on whatever is operationally simpler.
Perform this test to know what “N” really is: If your department merged with a department of the same
size, doing the same job, which storage requirements would double? It is these factors that reveal what
the value of “N” is for your circumstances.
And, of course, the detail order record would be one such item. So, where are the savings? The above
recommendations will save 9 bytes per record. If you write the code in RPG, this does not seem like
much. That would be 9 bytes times the number of jobs used to process the incoming records. After all,
there is only one copy of the record in a typical RPG program.
However, one must account for data base. Especially when accessing the records through an index of
some kind, the number of records data base will keep laying about will be proportional to “N” -- the total
number of outstanding orders. In Java, this can be even more clear-cut. In some Java programs, one
processes records one at a time, just as in RPG. The most straightforward case is some sort of “search”
for a particular record. In Java, this would look roughly the same as RPG and potentially consume the
same storage.
However, Java can also use the power of the heap storage to build huge networks of records. A custom
sort of some kind is one easy example of this.
In that case, it is easy for Java to contain the summary record and “dozens” of detail records, all at once,
all connected together in a whole variety of ways. If necessary, modern applications might bring in the
entire file for the custom sort function, which would then have a peak size at least as large as the data base
file(s) itself or themselves.
Once you get above a couple hundred records, even in but one application, the storage savings for the
record scrub will swamp the currency table savings. And, since one might have to buy for peak storage
usage, even one application that references thousands of detail records would be enough to tip the scale.
A Short but Important Tip about Data Base
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 20 - General Tips and Techniques
319
