O''''Reilly Network For Information About''''s Book part 166 potx

1. When all entries in the main object table have been checked, we report the
results to the user. Assuming that the user wants us to rebuild the file, we
start phase two. After opening a new quantum file where we will store the
rebuilt file, we examine each quantum containing actual user data, skipping
any quanta containing the main object table, big pointer arrays, and little
pointer arrays. For each such user-data quantum, we extract the object
number to which that quantum belongs, and add the elements in that
quantum to the appropriate element of the corresponding object in the new
quantum file, using the index number of each element as stored with the
element.
Chapter dynhash.htm
1. Modifications to add capabilities to the dynamic hashing implementation:
1. Deleting records is almost exactly the inverse of adding records.
Every time the number of records decreases by the average number of
records per slot, we take the storage element from the highest-
numbered slot and combine it with the one from its buddy slot,
placing the result back in the buddy slot. Then we decrease the active
slot count by one. If the active slot count becomes equal to one-half of
the allocated slot count, we halve the allocated count.
2. The main problem with duplicate keys is that since records with the
same key will always wind up in the same storage element, they make
it imperative to handle the overflow problem. Once that is solved,
handling duplicate keys is easy: once you have located all storage
elements that might contain records with that key, search each of them
to the end, rather than stopping when you get a match. Of course, you
then have to decide which record you want to use, but that's an
application-specific problem.
2. This is a wonderful application for templates. Even the name of the class is
intended to suggest that it could very easily be changed to
PersistentArray<type>.
Chapter zensort.htm

1. One fairly obvious way to handle the problem of improper key distributions
for the "divide-and-conquer" versions of the program is to use the
information gained in the first pass to determine which algorithm to use. If
the keys are reasonably uniformly distributed, then the "divide-and-conquer"
version will have the best performance and should be used; however, if the
keys are not uniformly distributed, the program should fall back to an earlier
version of the algorithm that will work properly and efficiently with a
skewed distribution of keys.
Footnotes
1. Hash coding can also be used to eliminate binary or linear searches through
tables in memory.
2. Caching can also be used to reduce processor time during searches of tables
in memory, as the most recently or most frequently referenced items from
the table can be kept in a cache.
3. A remarkable example of such hyperconservatism is the following
statement, from an otherwise fine book by Edward Yourdon: "As a
programmer, you will always be working for an employer. Unless you are
very rich and very eccentric, you will not enjoy the luxury of having a
computer in your own home ". (emphasis in the original) Yourdon, E.
Techniques of Program Structure and Design. Englewood Cliffs, New
Jersey: Prentice-Hall, Inc., 1975, pp. 2-3. This clearly ranks with the worst
predictions of all time.
4. An excellent explanation of this important mathematical discovery can be
found in Douglas Hofstadter's book Goedel, Escher, Bach. New York:
Vintage Books, 1979.
5. They're the ones with the arrows in their backs.
6. Interestingly enough, the previously cited passage in Yourdon's book goes
on to say: "In short, you cannot be an artist, separate and aloof; it is highly
unlikely that the programming community will ever generate a
Michaelangelo or a Rembrandt". This is quite a difficult standard to meet:

how many artists of this stature have come from any field, including
sculpture and painting? While the jury is still out on this prediction, I think
we will see a great artist of programming one of these days, although his or
her work might be inaccessible to the lay public.
7. Why is memory only "almost" a true random access device? Because the
processor is much faster than the main memory of the computer; therefore,
frequently used memory locations are copied into much faster memory
either on or very close to the processor itself. This means that accessing
locations in widely scattered parts of memory is likely to be noticeably
slower than sequential access to memory. However, the difference in speed
may be a factor of three or four rather than the relative speed difference of
hundreds or thousands of times that we see between sequential and random
disk accesses, so optimizing memory accesses is not as great a concern to us
as the latter problem.
About the Author
Steve Heller had always been fascinated by writing. In his childhood days in the
1950s and 1960s, he often stayed up far past his bedtime reading science fiction.
Even in adulthood, if you came across him in his off-hours, he was more likely to
be found reading a book than doing virtually anything else.
After college, Steve got into programming more or less by accident; he was
working at an actuarial consulting firm and was selected to take charge of
programming on their time-sharing terminal, because he was making much less
than most of the other employees. Finding the programming itself to be more
interesting than the actuarial calculations, he decided to become a professional
programmer.
Until 1984, Steve remained on the consuming side of the writing craft. Then one
day he was reading a magazine article on some programming-related topic and said
to himself, "I could do better than that". With encouragement from his wife of the
time, he decided to try his hand at technical writing. Steve's first article submission
to the late lamented Computer Language Magazine was published, as were a

dozen more over the next ten years.
But although writing magazine articles is an interesting pastime, writing a book is
something entirely different. Steve got his chance at this new level of commitment
when Harry Helms, then an editor for Academic Press, read one of his articles in
Dr. Dobb's Journal and wrote him a letter asking whether he would be interested
in writing a book for AP. He answered, "Sure, why not?", not having the faintest
idea of how much work he was letting himself in for.
The resulting book, Large Problems, Small Machines received favorable reviews
for its careful explanation of a number of facets of program optimization, and sold
a total of about 20,000 copies within a year after publication of the second edition,
entitled Efficient C/C++ Programming.
By that time, Steve was hard at work on his next book, Who's Afraid of C++,
which is designed to make object-oriented programming intelligible to anyone
from the sheerest novice to the programmer with years of experience in languages
other than C++. To make sure that his exposition was clear enough for the novice,
he posted a message on CompuServe requesting the help of someone new to
programming. The responses included one from a woman named Susan, who
ended up contributing a great deal to the book; in fact, about 100 pages of the book
consist of email between Steve and Susan. Her contribution was wonderful, but not
completely unexpected.
What was unexpected was that Steve and Susan would fall in love during the
course of this project, but that's what happened. Since she lived in Texas and he
lived in New York, this posed some logistic difficulties. The success of his
previous book now became extremely important, as it was the key to Steve's
becoming a full-time writer. Writers have been "telecommuting" since before the
invention of the telephone, so his conversion from "programmer who writes" to
"writer" made it possible for him to relocate to her area, which he promptly did.
Since his move to Texas, Steve has been hard at work on his writing projects,
including Introduction to C++, a classroom text that covers more material in the
same space as Who's Afraid of C++? at the expense of the email exchanges in the

latter book, followed by Who's Afraid of Java?. Their latest project is Who's Afraid
of More C++?, which came out in 1998.
Steve and Susan were married in 1997.








•


Table of Contents

•


Index

•


Reviews

•


Reader Reviews

•


Errata

Oracle PL/SQL Language Pocket Reference, 2nd Edition

By
Chip

Dawes
,
Steven

Feuerstein
,
Bill

Pribyl





Publisher
:
O'Reilly

Pub Date

:
February
2003
ISBN
: 0-596-
00472-9

Pages

: 127


The new edition of this must-have pocket guide boils down the most vital
information from Oracle PL/SQL Programming, the bestseller that many consider
"the Bible" for PL/SQL development. This concise booklet summarizes features
available in Oracle's powerful new product Oracle9i and provides essential
information on PL/SQL block structure, fundamental language elements, control
statements, and use of procedures, functions, packages, triggers, Oracle objects,
external procedures, and methods of calling Java classes from PL/SQL.