Infobright Blog

My last entry was about feature bloat.  

Why do I care about feature bloat?

Well, I care because it is, in a sense, clutter.  Clutter and I don’t have a great relationship.  I have always been a bit of design freak.  I can’t recall at the moment who said it, but truer words than these have not been spoken, "Good design makes complex things simple."

My favorite example of bad design is the clock radio.  I do have one that wakes me faithfully every morning.  Well every morning except those when I experience alarm failure!  The problem: when you set the alarm you need to hold down one button to choose to adjust the alarm setting while you also hold down another button to change the hour or minute. Of course if you choose to use one hand (and the buttons are so close together its hard to use two hands), inevitably you lift the wrong finger and you change the time. So by the time you get the alarm set, you need to go back and reset the time! Then there is that little annoying light that indicates AM and PM which you may or may not notice.  Such a simple concept designed into complete frustration.

Can something be everything to everyone for all purposes? Well you can, for example, carry a Swiss Army knife but given the choice wouldn't you rather have a real screw driver than that bottle cap opener/screw driver combination fixed to a handle that has no leverage?  Sure, many things can become functional replacements.  I can use my high heels as a hammer but they don’t work very well and are way too expensive to replace.

I think this is the place to where databases (and a few other products) have evolved. They do so many things, but they are not particularly good at any one thing without a lot of work and fine tuning.  At least for data warehousing.

As just one example consider this: do you have to use a star schema to make the warehouse work efficiently? What then about a business user?  Does that schema make sense to them?  Does it not limit them when they have multiple fact tables?  "You can't/don't joint those fact tables, the system will be on its knees!"  

Stay tuned and I will give you my thoughts on requirements for a DBMS for a data warehouse.