Much as I enjoyed spending time in San Diego at NCR I still believe that Teradata is dead.
The fundamental design of the late 80's/early 90s Teradata (database machine) lent itself to a single key for access efficiency, therefore you ended up with a lot of Teradata databases containing the same data, but for different application purposes organized along different partition keys.
I haven't kept up with the NCR product line since the mid-90s cuz their market share was trivial and essentially NCR couldn't find its ass with both hands following the mergers that took place. Their UNIX line dropped far behind Sun, IBM and HP in the US. They never figured out a smooth transition plan from Teradata big iron to UNIX, and they had competing in-house groups that were fighting for R&D dollars, the Oracle parallel server on their UNIX hardware line being one of the options. Their architecture never lent itself to ad hoc queries, only carefully constructed queries that relied on the partition key. Keep in mind that NCR is the same company that was JOINTLY engages with SYBS to bring out their super scalable, parallel query engine. Still waiting on SYBS for that one. It was clear to me that NCR had thrown in the towel in 1994.. SYBS was still selling the HELL out of the future of this crap in 1997!
$14M seems pretty cheap, but what did they really get? A bunch of dead end R&D in my opinion. I'm not trying to diminish the power of a big Teradata database for its intended purpose, but it won't handle generated SQL unless is is CAREFULLY aligned along the parallel key. Period. This is a marriage that will yield brain dead children, if they can even put tab A in slot B. A cube product from NCR. That I'll believe when I see it.
--Difference between an OLTP and DSS database-- Duh. Think I have that one fairly well in hand. Have built quite a few of both, but most often I try to incorporate the necessary DSS elements into the OLTP design. I really hate to handle an OLTP transaction twice - once to do it in the first place and second to warehouse the damn thing. And that is optimistic. In a BIG teradata environment that poor transaction probably gets loaded into a bunch of DSS databases.
--SQL generation engine from MSTR-- Well I hope it is a hell of a lot better than it was 4 years ago. I've never seen shit SQL (pardon my french) worse than what came out of this esteemed engine. The EXPLAIN plans were quite interesting to look at. Meanwhile the consultants from MSTR whined about the terrible job the database did of optimizing the crap that comes out of that engine. I spent hours with the cost based optimizer designers at Oracle trying to improve the performance of this 'generated' SQL, to no avail. Laughter was frequently heard from the other end of that phone when evaluating the explain plans and generated SQL. This 'engine' really wasn't much of an engine at all, since it was largely built to spec on-site and was almost totally application/industry/database design specific. BTW, this is the cruz of my comment that MSTR is a consulting company. The idea that MSTR has a generalized query engine that is highly performant is a crock. Today some pick lists embedded in Java could pretty easily obtain the same parameters and generate better SQL because the application designer would have COMPLETE control over WHERE clause construction. Hey maybe I'll build one, we'll call it an 'engine' and compete head to head with MSTR... Slap a nice presentation interface on it. Call it DSS Agent and BANG! We are off to the races. Or is that name taken?
Keep in mind that the only term I dislike MORE than 'business intelligence' is 'data warehouse'. It is a poor analogy. We can all thank companies like IFMX who took this analogy way too far. I used to do the data warehouse presentations for one of these vendors around the country and I used to puke after every one because as a database designer, the whole concept of segregating data into something as trite as a data warehouse really minimized the need to do GOOD analysis as part of the application and take into account the storage of aggregates and time series data as PART of the application, not as some shit shovelled into a separate holding tank called a data warehouse. <-- worlds longest run on sentence ;) The VAST majority of pure data warehouse projects I have seen contain a LOT of data that is NOT used by anyone, but it is nicely stored. Very few of these projects really deliver value. The real question 'how many widgets did we sell on the east coast in Q3' doesn't require a data warehouse to answer. It required us to define the necessary aggregates as principal entities in the original application and update them real time as transactions were processed. Time series analysis (and other dimensional analysis) is OFTEN omitted from the original application design and then the salesman from MSTR shows up with his demo and slides...
The WHOLE concept of warehousing immense amounts of data for access by generalized query engines that can MAGICALLY massage these HUGE amounts of data and return real time (or anything approaching it on ANYBODYS database or hardware platform) is just not for real. It wasn't when I was selling it. It wasn't when I was selling it JOINTLY with MSTR. And it still isn't there.
My two cents worth. I turn the soapbox back over to you.
BTW, I missed by $3. The wormed turned at $72. Tough sledding from here on out. They'll announce a split soon to keep the ball rolling no doubt. Hey, we've seen it work everywhere else -- go for it Saylor. A 3 for 1 at these levels should push you to $90 for XMAS. This smells like a beer bet brewing.
ttf |
