Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : Red Brick Systems -- Ignore unavailable to you. Want to Upgrade?

To: Ray Rueb who wrote (173)	2/6/1998 10:44:00 AM
From: Smilodon	Read Replies (1) \| Respond to of 304

Ray, Thanks for the comments Ray. Actual user comments are more valuable than anything financial types like myself can contribute. While you are at it, here is a short idea I am working on that you may have knowledge of: Due to the Y2K issue, a lot of companies have sought to replace problem systems rather than fix them. However, once the lead time for implementation exceeds their deadline, they must focus resources on fixing legacy systems. Compounding that problem is that a lot of potential ERP customers, especially the larger ones have already bought their systems. Result is a possible slowdown for the enterprise software companies. Combine this with their very high valuations could lead prices off a cliff. Names I am investigating are PeopleSoft, SAP, Baan and maybe Seibal (I know they are a little different) Any knowledge of this area? Thanks

To: Ray Rueb who wrote (173)	2/6/1998 10:45:00 AM
From: Mark Finger	Read Replies (1) \| Respond to of 304

Have you looked at IFMX, especially what used to be called the XPS version 8.2 (they renamed the entries in their line recently). Consider the following: >>3) Good performance in multi table joins, even when joining 14 >>tables together. This was important for us because Marketing >>frequently requires 12 months of data to even begin working on a >>decent model. In Oracle we have to avoid this by spending the time >>and space to pull all the desired months into a single record for >>each person or product. In particular, IFMX allows you to build multi-table join indices to reduce part or most of the time involved in complex joins, and you do not have to do the Oracle thing of "denormalizing" the data for performance. >>3) Totally hit a wall at 600Gb (though now this may no longer be >>true) What is the 600G limit based on? cleaned, raw data? sum of loaded data? with/without indices? IFMX has reference sites with more than 1T of raw data (the smallest size used to characterize data sizes). Cornell University is doing research on a 500 node IBM SP2 that will go well beyond that size, to see what kind of things warehouses can do. Incidentally, one of the key size characteristics of IFMX is the limit of about 60T as the maximum size of a single table. >>4) Loader much slower than Oracle's (Again, may no longer be true) IFMX loaded seems to be 50% faster than Oracle (especially Oracle 7) based on same or similar equipment benchmarks (see the TPC/D benchmarks). >>5) Forced us to use the Star schema, which was counter to our >>experience and infrastructure. I do not think IFMX would force this kind of requirements on you. I list the above not necessarily to convert you, although I still have IFMX stock and have a soft spot in my heart for them (I used to work there). The above also would demonstrate the problems that Red Brick has in getting into larger sites, or into sites that expect to scale to larger sizes (many of the companies expect their warehouses to grow very significantly over time). In other words, Red Brick must get past IFMX and IBM just to get to 2nd place on the list (assuming ORCL is first), and many companies do not want to do extensive evaluation past 2 finalists. Mark PS. To those who look at competitors, MSFT is in at least 5th place technically for complex query and other warehouse support (behind ORCL, IFMX, IBM, and SYBS), and simply does not have much in terms of references because they are only now adding the kind of technical features needed to support warehousing (and who knows when they will actually ship?).

To: Ray Rueb who wrote (173)	2/6/1998 2:06:00 PM
From: Fred Fraschetti	Read Replies (1) \| Respond to of 304

Can we buy SAPHY here in the states?

To: Ray Rueb who wrote (173)	2/13/1998 6:54:00 PM
From: Red Brick DBA	Read Replies (1) \| Respond to of 304

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