Typical bogosity — the “censorship” furor
Fabian Pascal and Alf Pedersen are complaining endlessly about Computerworld having censored some comments of theirs, in response to blog posts of mine (the first of which was a response to Alf’s blog post in response to my August column). They even seem to have gotten Tom Kyte worked up about it.
So let me be very, very clear.
1. I never had the right or ability to edit or censor comments.
2. I opposed almost all the editing and censoring that did occur.
3. I vehemently opposed the policy of editing comments (mine or anybody else’s) without a posted notice to the effect that they’d been edited, because that amounts to putting words into somebody’s mouth they didn’t actually say. This is the prime reason I no longer blog at Computerworld. (Had Computerworld had a posted warning about the likelihood of editing, as newspapers have on the Letters to the Editor page, I might have felt less vehement. But they have no such notice, or if they do it’s buried out of sight in a long legalistic Terms of Service page somewhere.)
4. I don’t recall ever suggesting the removal or editing of any comment whatsoever, except for one garbled non sequitur that wasn’t in a DBMS2-related thread.
5. I have a pretty good idea of why some posts were censored, based on direct communication with the editor in question, and it had to do with tone and nastiness and promotion of people’s websites, not with the substance of their comments. There’s only a slight chance I’m wrong about that. Indeed, I’m pretty sure he doesn’t have the technological knowledge to understand, for example, the main differences between Pedersen’s opinion and mine.
Let me stress that all this applies only to the blog editor, who’s a very different kind of person from the other editors it has been my pleasure to work with at Computerworld.
| Categories: About this blog | 6 Comments |
The Amazon.com bookstore is a huge, modern OLTP app. So is it relational?
I don’t know for a fact that the Amazon.com bookstore is the world’s biggest OLTP application — but if it isn’t, it’s close.
And the thing is — that’s never been an entirely relational application. Oh, the ordering part surely is. But the inventory lookup is currently driven by an OODBMS (from Progress). The personalization used to be done in Red Brick (I knew which software replaced it, but I’m forgetting at the moment — it may even be one of the relational warehouse appliance vendors). And of course the full-text search is a custom in-house system.
| Categories: Amazon and its cloud, Cache, Data types, Database diversity, Memory-centric data management, Object, OLTP, Progress, Apama, and DataDirect, Specific users | 4 Comments |
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 |
Restarting this blog; comments policy
I was going to let this blog sit idle until I could get around to dressing up its look and feel more. But I don’t want to wait for that, nor take the trouble to do it quickly, so what you see is what you get. Please excuse any dust or exposed girders.
For now, we’ll go with a very simple policy on comments.
1. I reserve the right to delete any comment at any time for any reason, without notice. The same goes for closing off comments, in a thread or overall in the blog.
2. If I EDIT your comment and still leave it up over your name, I will post a notice saying I’ve done so. I feel strongly about this; the blog editor’s refusal to adopt the same policy is the principal reason I no longer blog at Computerworld, despite the high regard in which I hold the print publication and almost everybody on the staff. (I continue to be very happy as a columnist there.)
3. The usual no-nos are forbidden here — plagiarism, spam, death threats, etc.
| Categories: About this blog | Leave a Comment |
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 |
Open source DBMS — easier to install?
Lewis Cunningham compared the installation ease of Oracle, PostGRES and MySQL. Despite expecting Oracle to win (uh, why?), he wound up ranking PostGRES first, with Oracle and MySQL tied — and that’s after marking MySQL down (indirectly albeit not directly) for lacking documentation in a beta release.
This just goes to show: The inherent complexity of the high-end products can outweigh users’ greater familiarity with them.
Besides, ever more people — especially cheap recent grads — are familiar with MySQL.
EDIT: Cunningham has a little more to say here.
Technorati Tags: Database, DBMS, DBMS2, MySQL, Oracle, PostGRES
| Categories: MySQL, Open source, Oracle | 1 Comment |
Oracle vs. open source DBMS
Mark Rittman had a great thread last November questioning the need for Oracle’s advanced features at most installations.
Pretty similar to what I’ve been saying, but more from a developers’ or DBA’s standpoint than a CIO’s.
Technorati Tags: Database, DBMS, DBMS2, Oracle, MySQL
| Categories: Microsoft and SQL*Server, MySQL, Open source, Oracle | Comments Off on Oracle vs. open source DBMS |
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! |