Theory and architecture
Analysis of design choices in databases and database management systems. Related subjects include:
- Any subcategory
- Database diversity
- Explicit support for specific data types
- (in Text Technologies) Text search
Or to put the core idea another way
Break the data management problem into pieces, and stitch the pieces together.
Some of the pieces are best managed relationally, for all the well-known reasons; some, especially but not only the document-oriented ones, are not. XML-based SOA, or a successor, is the right framework for most of the stitching.
| Categories: Database diversity, Theory and architecture | Leave a Comment |
The core idea(s) of DBMS2
My introduction of the DBMS2 concept in an August Computerworld column has excited some heated discussion, little of it focused on what I regard as the core issues. But I must concede that in a short series of monthly 750 word columns (two published so far), with a target audience of senior IT managers, I have not necessarily made a clear statement of whether or why database designers should agree or care.
So here’s a little more of that story.
1. Everybody knows that large enterprises do not have single enterprise-wide data models, nor do they have single integrated enterprise databases, managed by a single DBMS.
2. The situation described in Point #1 is inevitable. Deal with it. Stop your futile efforts to change it.
3. What’s more, the obvious disadvantages to the situation in Point #1 are outweighed by other strong TCO advantages. Different kinds of data models, and different kinds of DBMS (or DBMS-substitutes) are appropriate for different applications and data sets.
That’s it.
Some supporting arguments may be found in my column appearing today (see other post). Most of the ones I had room for boil down to this:
Relational databases are ideally suited to manage facts. Most interesting new applications don’t deal (primarily) with the management of facts.
| Categories: Database diversity, Theory and architecture | 2 Comments |
Loose coupling = TCO savings
Andrew Clifford is introducing an apparently new consultancy called Minimal IT, a great idea in itself. In his introductory newsletter article, he attacks the concept of having a centralized database at all, whether physically centralized or federated. Bravo!!
When DBMS2 comes to full fruition, years down the road, it will be possible to have the TCO benefits of loose coupling AND in some sense have a single integrated enterprise database (or something pretty close to it). But in the mean time … in the real world? Go with the TCO savings.
| Categories: Theory and architecture | Leave a Comment |
The end of the single-server DBMS vendor
For all practical purposes, there are no DBMS vendors left advocating single-server strategies. Oracle was the last one, but it just acquired in-memory data management vendor TimesTen, which will be used as a cache in front of high-performance Oracle databases. (It will also continue to be sold for stand-alone uses, especially in the financial trading and defense/intelligence markets.)
IBM’s Viper is a server-and-a-half story, with lots of integration over a dual-server (one relational, one native XML) base. IBM also is moving aggressively in data integration/federation, with Ascential and many other acquisitions. It also sells a broad range of database products itself, including two DB2s, several Informix products, and so on.
Microsoft also has a multi-server strategy. In its case, relational, text, and MOLAP storage are more separate than in Oracle’s or even IBM’s products; again, there’s a thick layer of technology on top integrating them. An eventual move to native XML storage will, one must imagine, be handled in the same way.
Smaller vendors Sybase and Progress also offer multiple DBMS each.
Teradata is a pretty big player with only one DBMS — but it’s specialized for data warehousing. Teradata is the first to tell you you should use something else for your classical transaction processing.
The Grand Unified Integrated Database theory is, so far as I can tell, quite dead. Some people just refuse to admit that fact.
| Categories: Database diversity, IBM and DB2, In-memory DBMS, Microsoft and SQL*Server, MOLAP, Oracle, Progress, Apama, and DataDirect, Sybase, Teradata, Theory and architecture | 3 Comments |
Down with database consolidation!
As with all changes in information technology, the move to DBMS2 will largely be one of evolution. But it does have a couple of revolutionary aspects.
Short-term, the biggest change is a renunciation of database and DBMS vendor consolidation. Consolidation never has worked, it never will work, and as data integration technologies keep improving it’s not that important anyway.
IBM and Oracle offer really great, brilliantly complex data warehousing technology. But if you want the most bang for the buck, forget about them, and go instead with a specialty vendor. Depending on the specifics of your situation, Teradata, Netezza, Datallego, WhiteCross, or SAP may offer the best choice, and that list could be even longer.
Similarly, for generic OLTP data management, cheap and/or open source options are getting ever more attractive. Microsoft is a serious contender for applications that previously only Oracle and IBM could handle, while MySQL and maybe Ingres are moving up the food chain right behind.
In many cases, these alternative technologies are lower-cost across the board: Lower purchase price, lower ongoing maintenance fees, and lower administrative costs.
So what, again, is the case for consolidation?
| Categories: Actian and Ingres, Analytic technologies, Data warehouse appliances, Database diversity, IBM and DB2, Kognitio, Memory-centric data management, Microsoft and SQL*Server, MOLAP, MySQL, Netezza, Open source, Oracle, SAP AG, Theory and architecture | Comments Off on Down with database consolidation! |