Counterpunching in the DBMS2 Debate

Computerworld - Recently, I've been writing a great deal about data architectures for the future, often under the rubric of "DBMS2." This has ruffled some feathers, including those of database textbook author C.J. Date. Summarizing the whole debate in this limited space is hopeless, but here is a quick tour through some issues that traditional database experts seem to be overlooking.
1. Logical and physical modeling will never be completely separable. A DBMS is, first and foremost, an execution engine for Data Description Language/Data Manipulation Language. To say that logical modeling need not take performance into account is to say that DDL/DML programming need not take performance into account. Wrong. No matter how great your optimizing compiler is, you still can write a slow program; the same principle applies to DBMSs. Indeed, it's even more valid for data modeling than for some other kinds of programming. The higher the level your mistakes are, the harder it is for the optimizer to fix them - and little is higher level than database design.
2. "True relational" DBMSs are very unlikely ever to be practically useful, except perhaps in narrow niches. The gurus claim that a true relational DBMS would allow the complete separation of logical and physical modeling. But as noted above, that will never be practical, at least not in a broad-spectrum, industrial-strength product. Date's beloved "TransRelational" architecture doesn't magically invalidate this point. As for claims of "orders of magnitude" of performance improvement, even if they are true, benchmarks and prototypes are a far cry from versatile, industrial-strength reality.
3. Enterprises don't fully control their data models. A coherent, enterprisewide data model may be a wonderful idea, but it's not something you can implement with any precision - unless you get your whole company to run a single-vendor suite of applications, and perhaps not even then. Purchased apps -- and acquired companies -- mean that your data model is largely defined by other folks.
4. Duplicated data is not inherently bad. Some database gurus abhor duplicated data, based on the presumption that it is hard to keep this data consistent. Taken to the extreme, this would proscribe all of data warehousing. Most of the gurus know better than that, of course, and would quickly concede that read-only duplication is OK, if deployment economics demand it. Rather, what they deplore is duplicated data that is updated in two or more places. But haven't they ever heard of an index? Also, every DBMS maintains duplicate copies of data as part of its essential workings.