Database Reference
In-Depth Information
optimized BSo cubes, this was not a simple directive to fulfill. I could not just go chop
off some fluff inside the cube and provide the requested disk reduction. “Well,” I said
to myself, “I guess I have no choice except to try this ASo thing. It probably will not
work, and my terrifically designed cubes will really not run well, but I need to be able
to tell them I tried and to go ahead and just purchase more disk space; after all, disk is
cheap.” So, I set off and started converting cube after cube. The results were staggering.
hours on hours were knocked of of our load and calc each night and weekend. our disk
footprint was reduced to a mere 20% of the original amount of disk. In most instances,
although not all, the users' reports were faster. From that day forward, I was a convert
and I have never looked back or regretted that move. I only wish I had jumped on the
band wagon sooner and begun embracing the ASo technology immediately instead of
waiting so long. to quote an old idiom—better late than never. At least I had not missed
the entire party, and now neither will you.
one of the simpler methods to learn what an ASo cube does is to compare it to
something you are intimately familiar with: the BSo cube. The easiest way to review
a summary of the functionality or capabilities available in an ASo cube versus a BSo
cube is in a table format. Drawn together from a great many sources, the following
is a high-level summary comparison to assist you in working through your decision
process. not every BSo cube is an appropriate candidate to become an ASo cube. The
decision on whether to convert it or not should be a purposeful move. table 5.1 is not
considered to be an all-inclusive table of every function or capability available within
the two complementary technologies. Some of these facts may surprise even seasoned
developers.
This type of list was first produced by consultants in the early adoption of ASo tech-
nology. I wish I had some of my earliest comparison papers and lists; the comments I
wrote in the margins would be very interesting to read (and laugh about) now. typically,
a new version of the software would be released. We would download and install it and
then take it for a test run with our favorite “difficult” application (because everyone
knew that all releases look good when you run Sample or Demo Basic) and our favorite
front-end tool. After we had it properly installed and fully loaded, we would do our
checkbox comparison. With each new release what we found to be happening is that
there were fewer blanks or negatives on the ASo column, and more blanks or nega-
tives on the BSo column. Slowly but surely, ASo started having a greater number of
advantages than disadvantages. Finally, I think we can openly declare that there is a new
development standard. The “new norm” among many respected developers is that you
always design using ASo cubes, falling back to BSo cubes only when absolutely neces-
sary (and mostly in context with Planning Applications as well as homegrown budget-
ing/forecasting applications).
“Should I immediately start converting all my BSo cubes to ASo cubes?” no, defi-
nitely not. There are some key questions and considerations to think about before launch-
ing on a large or small conversion project. Determining if your BSo cubes are good
candidates for conversion is not necessarily a straightforward task and there are a lot of
things to consider. hopefully, the next few pages will help with that task. Approaching
it analytically with an open mind will allow you to accurately determine the best course
of action for existing cubes. Just as important in this process, though, is the need to start
thinking through which technology should be used for new implementations, and why.
Don't be like I was and stay with BSo cubes only because it is what you know, and more
importantly, what makes you comfortable. use this resource guide to empower you to
