Hi again:
This is to continue my post (#181 I think), correcting negative REDB stereotypes.
>Now the negative stuff:
>1) None of our potential customers had ever heard of them (though >now some of them are REQUESTING Red Brick bids)
Yay! Hope that keeps going.
>2) Impossible to find experienced DBA's, or semi-experienced ones, >or developers, or database designers.
Don't need a DBA or database designer familiar with REDB. Take any old DBA. You can train them in 5 days to be a REDB DBA. As for developers, I assume the same is true. There just isn't as much to know about REDB as there is about Oracle or others. Anyway, most companies BUY their OLAP apps these days.
>3) Totally hit a wall at 600Gb (though now this may no longer be true)
Yes ... not true. Again, talk to Tandy -- 2TB and growing.
>4) Loader much slower than Oracle's (Again, may no longer be true)
Absolutely not true. The REDB loader will run circles around the Oracle loader.
>5) Forced us to use the Star schema, which was counter to our >experience and infrastructure. My company's competitive advantage >is that we can build a single table (or a small set of tables) >containing all columns necessary for Marketing selections using a >proprietary tool we call "the flattener". Red Brick's technology would >have allowed us to join many tables together to dynamically achieve >the same goal, but the Marketing users couldn't seem to grasp the >concept. And always remember: the users' ability to use the system >is the only thing that really matters in a data warehouse.
Hmmm ... the flattener sounds intriguing. You could've built views in REDB to shield your users from the normalized tables. The cool thing about the REDB optimizer and views is that it recognizes when you only need to query a subset of the tables contained in the view and will only issue the query to those tables and not the unnecessary ones. This isn't true of every database and it's a big plus.
>6) Oracle caught up with the Red Brick technology, and Oracle >scales well to 4Tb (and we assume beyond) when used on a >Pyramid MPP.
Again, see my recent post on this subject. Oracle is struggling to catch up to REDB. Hasn't quite made it. And the fact that you have to throw all that big iron and complexity (MPP systems are very difficult to manage and write apps for) at the Oracle database ... well, doesn't that tell you something? Actually, the fact that it's 4 TB is also revealing. 2TB of it is probably temp/sort space needed to rebuild all their large indexes when the loader invalidates them. I'm currently building an Oracle 8 decision support database that will have about 3 GB for the 1st month's data. The temp/sort space will be nearly 2 GB.
Well, another of my 2 cents' worth. With the previous 2 cents, that makes 4 cents and I'm probably over my limit, so I'll stop now.
Red Brick DBA |
