Database management systems
Historical notes on the database management system (DBMS) business. Related subjects include:
In my recent Stonebraker-oriented post about database theory and practice over the decades, I wrote
I used to overrate the importance of abstract datatypes, in large part due to Mike’s influence. I got over it. He should too. They’re useful, to the point of being a checklist item, but not a game-changer. A big part of the problem is [that] different parts of a versatile DBMS would prefer to do different things with memory.
and then left an IOU for a survey of abstract datatypes/RDBMS extensibility. Let’s get to it.
Perhaps the most popular term was actually object/relational DBMS, but I’ve never understood the etymolygy on that one.
Although I call RDBMS extensibility a “checklist item”, the list of products that can check it off is actually pretty short.
- PostgreSQL has the granddaddy implementation.
- Its ideas were commercialized as Illustra, which was bought by Informix, which later was bought by IBM.
- Oracle has one of the major implementations.
- IBM has one of the major implementations.
- Sybase has struggled with implementing the technology.
- So did Microsoft SQL Server, which of course started with the Sybase code line.
Surely there are more, but at the moment I can’t really think of which they are.
|Categories: Database management systems, IBM, Informix, Ingres, Microsoft, Oracle, Sybase||2 Comments|
This is part of a three-post series on enterprise application software over the decades, meant to serve as background to a DBMS2 post on issues in enterprise apps.
- The first lays out very general issues in understanding and subdividing this multi-faceted sector.
- The second calls out characteristics of specific application areas.
- The third (this one) discusses application software products’ underlying technology.
0. I’d like to discuss the technology underneath packaged application software. To create some hope of the discussion being coherent, let’s split apps into a few categories:
- Major/core suite, large enterprises – e.g. ERP (Enterprise Resource Planning).
- Major/core suite, smaller enterprises — e.g., the province of Progress and Intersystems VARs (Value-Added Resellers).
- Remarkably distributed applications. This is where a lot of the more unusual technology choices cluster.
- Other point solutions. Sometimes, a guy just needs a catch-all category.
1. The idea of bundling ERP (or its predecessor MRP) with an underlying DBMS has been around for a long time.
- Cullinet and Cincom tried it, but with pre-relational DBMS. Oops.
- Oracle has always had that strategy.
- A sizable minority of SAP’s customers ran
And for smaller enterprises, it has been the norm, not the exception.
|Categories: Application software, Cullinet, Database management systems, IBM, Informix, Microsoft, Oracle, Pre-relational era, SAP, Sybase||3 Comments|
Larry Ellison had an official job change, and will be CTO and Executive Chairman of Oracle — with the major product groups reporting to him — instead of CEO. I first met Larry 31 years ago, and hung out with him quite a bit at times. So this feels like time for a retrospective.
For starters, let me say:
- I met Larry Ellison the same year I learned of him, which was 1983. We were in fairly active touch until the late 1990s. Then we drifted apart. That period corresponds roughly to the eras I characterized in my Oracle history overview as Hypergrowth, Plateau, and Professionalism.
- With Larry as with other “larger than life” industry figures I’ve met, what you get in private and what you see in public are pretty similar. I’ve had high-intensity dinner conversations with Larry (numerous times), Bill Gates (a few times) and Ross Perot (once) that are quite in line with their public demeanors.
- With Larry, facts can be mutable things. The first time I met him, I came away with the impression he had a PhD. The second time, it was only a masters degree. Ten years later, he’d almost graduated from the University of Chicago, but had failed or not take a French exam. And I gather his educational resume has retreated a little further since.
- Larry is hilarious, in a scathing way, and an excellent story-teller. Unfortunately, his humor rarely translates well to out-of-context print.
Some anecdotes: Read more
As part of my series on the keys to and likelihood of success, I’d like to consider some historical examples in various categories of data management.
A number of independent mainframe-based pre-relational DBMS vendors “crossed the chasm”, but none achieved anything resembling market dominance; that was reserved for IBM. Success when they competed against each other seemed to depend mainly on product merits and the skills of individual sales people or regional sales managers.
IBM killed that business by introducing DB2, a good product with very good strategic marketing from a still-dominant vendor. By “very good strategic marketing” I mean that IBM both truly invented and successfully market-defined the relational DBMS concept, including such conceptual compromises as:
- Ted Codd’s 12 rules, not that anybody — even IBM — actually followed them all.
- SQL as the standard, rather than the probably superior QUEL.
In the minicomputer world, however, hardware vendors lacked such power, and independent DBMS vendors thrived. Indeed, Oracle and Ingres rode to success on the back of Digital Equipment Corporation (DEC) and other minicomputer vendors, including the payments they got to port their products to various platforms.* The big competitive battle was Oracle vs. Ingres, about which I can say for starters: Read more
I never met IDG founder Pat McGovern, who was the kind of tycoon that traveled around the world handing Christmas bonuses personally to every employee in his firm. Even so, McGovern’s passing seems like an occasion for recollections about IDG through the decades. And so:
1. My connections have always been much stronger with IDG (International Data Group) publications than with the analyst firm IDC that’s also part of the business.
2. I have at times been pretty connected to those pubs. For example:
- I’ve been a columnist for both Computerworld and Network World (the latter online-only).
- I’ve blogged for pay for both Computerworld and Network World.
- I’ve been outright interviewed by each, and quoted many times by them and other IDG publications as well.
3. Computerworld has probably always been the leading enterprise technology publication, including during the trade press’ glory years. Most memorably, pre-relational mainframe DBMS were claiming with some success to be “relational”. But when Computerworld reported Ted Codd’s “rules” for RDBMS, that was that — RDBMS were defined to be what Codd and Computerworld said they were, and the bottom dropped out of the market for DBMS that didn’t meet Codd’s criteria.
4. In line with its industry leadership, Computerworld had a classified ad section that ran dozens of pages. When I hired a research assistant in my stock analyst days, the obvious choice was to run the ad there.
5. To this day, if an ego-surf shows that I’ve been quoted in countries and languages around the world — Brazil, Australia, Iran or whatever — it’s usually something I said to IDG, which then translated and republished it around the world.
6. IDG is a big enough press organization not to be perfect. Read more
Recently I expressed doubts about Actian’s DBMS-conglomerate growth strategy. For context, perhaps I should review other DBMS vendors’ acquisition strategies in the past. Some — quite a few — worked out well; others — including many too minor to list — did not.
In the pre-relational days, it was common practice to buy products that hadn’t succeeded yet, and grow with them. Often these were programs written at enterprises, rather than third-party packages. Most of Cullinet’s product line, including its flagship DBMS IDMS, was came into the company that way. ADR, if memory serves, acquired the tiny vendor who created DATACOM/DB.
Then things slowed down. A Canadian insurance company oddly bought Computer Corporation of America, to utter non-success. (At least I got an investment banking finder’s fee on the deal.) Computer Associates, which did brilliantly in acquiring computer operations software, had a much rockier time with DBMS. It acquired Cullinet, Applied Data Research, and ASK/Ingres — among others — and didn’t have much growth or other joy with any of them.
Indeed, Ingres has been acquired three times, and hasn’t accomplished much for any of the acquirers (ASK, Computer Associates, Actian).
I used to think that Oracle’s acquisition of RDB provided key pieces of what became Oracle’s own extensibility technology. Andy Mendelsohn, however, disputed this vehemently — at least by his standards of vehemence — and his sources are better than mine. Rather, I now believe as I wrote in 2011:
… while Oracle’s track record with standalone DBMS acquisitions is admirable (DEC RDB, MySQL, etc.), Oracle’s track record of integrating DBMS acquisitions into the Oracle product itself is not so good. (Express? Essbase? The text product line? None of that has gone particularly well.)
Experiences were similar for some other relational DBMS pioneers. Read more
|Categories: Applied Data Research, ASK Computer Systems, Computer Associates, Cullinet, Database management systems, IBM, Informix, Ingres, Microsoft, Oracle, Sybase, Teradata||2 Comments|
I blogged a little last year about the rewards and challenges of combining professional services and software in a mature company’s business model. My main example was Oracle. But other examples from Oracle’s history might have been equally instructive. For example:
- Oracle started out doing what amounted to custom development for government (military/intelligence) clients.
- Even when Oracle said it had productized its software, the stuff didn’t work very well without services to get it running.
- Oracle and Ingres both got a huge fraction of their early revenue* from deals to port their software to various brands of hardware. That’s a lot like professional services.
- Oracle’s huge Tools Group grew out of professional services, if I have the story straight. Indeed, its first product was written by later long-time group chief Sohaib Abbasi when he was a consultant.
Roland Bouman reminded us on Twitter of an old post I did on another blog about Ingres history, the guts of which was:
Ingres and Oracle were developed around the same time, in rapidly-growing startup companies. Ingres generally was the better-featured product, moving a little earlier than Oracle into application development tools, distributed databases, etc., whereas Oracle seems to be ahead on the most important attributes, such as SQL compatibility — Oracle always used IBM’s suggested standard of SQL, while Ingres at first used the arguably superior Quel from the INGRES research project. Oracle eventually pulled ahead on superior/more aggressive sales and marketing.
Then in the 1990s, Ingres just missed the DBMS architecture boat. Oracle, Informix, Microsoft, and IBM all came out with completely new products, based respectively on Oracle + Rdb, Informix + a joint Ingres/Sequent research project, Sybase, and mainframe DB2. Ingres’s analogous effort basically floundered, in no small part because they made the pound-wise, penny-foolish decision to walk away from a joint venture research product they’d undertaken with innovative minicomputer vendor Sequent in the Portland, OR area.
Computer Associates bought Ingres in mid-1994, and immediately brought me in to do a detailed strategic evaluation. (Charles Wang telephoned the day the acquisition closed, in one of the more surprising phone calls I’ve ever gotten, but I digress … Anyhow, the relevant NDA agreements, legal and moral alike, have long since expired.) There was nothing terribly wrong with the product, but unfortunately there was nothing terribly right either. Aggressive investment — e.g., to get fully competitive in parallelism and object/relational functionality, the two biggest competitive differentiators in those days — would have been no guarantee of renewed market success.
Notwithstanding the economic question marks, CA surprised me with its enthusiasm for taking on these technical challenges. But another problem reared its head — almost all the core developers left the company. (If you weren’t willing to sign a noncompete agreement that was utterly ridiculous in those days, at least in the hot Northern California market, you couldn’t keep your job post-merger.) And so, like almost all CA acquisitions outside of the system management/security/data center areas, Ingres fell further and further behind the competition.
Some of the same information made it into my post here on Ingres history later the same year, but for some reason not all did.
Talking to Algebraix reminded me that David Childs is still alive and kicking. I only ever encountered Childs once, in the early/mid-1980s, when he was pushing his company Set Theoretic Information Systems. The main customer example for STIS was General Motors, for which he had achieved a remarkable amount of database compression. It was something like 4-5X, if I recall correctly, but for 1983 or whatever that was pretty darned good. The idea was to replace data by partitioning according to shared values. E.g., you didn’t store whether cars were red, blue, or green; instead, you stored records about all the red cars in one place, the blue cars in another, and so on. There was also some set-theoretic mumbo-jumbo, but I never figured out what it had to do with implementing anything.
Comshare — a BI vendor before anybody called it BI — did actually build a DBMS based on Childs’ ideas, as Ron Jeffries reminds us. It was relational. Eventually, if I recall correctly, it was swapped out for Essbase (the original MOLAP product, now owned by Oracle).
What Childs really focuses on, however, seems to be “Extended Set Theory.” (This was brought to my attention by Algebraix, even though Algebraix doesn’t actually use many of Childs’ ideas.) And he’s been doing it for a long time. Way back in 1968, Childs wrote a paper outlining how set theory, relations, and tuples could be applied to data management.
And that’s where I did a double-take, because 1968 < 1970. Sure enough, Footnote #1 in Codd’s seminal paper is to Childs’ 1968 work. Indeed, Childs’ paper is the only predecessor Codd acknowledges as having significant portions of his idea.
I’m far from convinced that “Extended set theory” has much to offer versus the standard relational model. But that debate quite aside — Childs’ original achievement doesn’t get the credit it deserves.
The top PostgreSQL-related April Fool’s joke this year, which seems to have successfully pranked at least a few people, was that Postgres is dropping SQL in favor of an alternative language QUEL.
Folks, QUEL was the original language for Postgres. And Ingres. And, more or less, Teradata.* I’d guess Britton-Lee too, but I don’t recall for sure.
*Once upon a distant time, when I was a cocky young stock analyst, I explained to Phil Neches, chief scientist of Teradata, just why it was a really good business idea to drop T-QUEL for SQL. I doubt he was convinced quite on that day, more’s the pity.