Follow @DBDebunk Follow @ThePostWest

1.
Links to exchanges I participated in were posted on the FP ONLINE page. In one of them I deplored the major effort invested in mindlessly migrating from fad to fad, rather than on sound productive work. One example:

How to move configurable xml data types and data to Oracle database

2.
A new To Laugh or Cry? item was posted on the LAUGH/CRY? page. Has some relevance to each of the other items mentioned in this update.

3.
The Quote of the Week was posted on the QUOTES page. It is a comment on Iggy Fernandez's blog post, a link to which I posted last week on the FP ONLINE page and which I recommend reading.

4.
The author of Hipsters hacking on PostgreSQL writes that OTOH PostgreSQL was designed to be "a relational counterpart to Oracle and DB2", but it is increasingly being used "not because it's the easiest database to learn and use. It's not ... [or] because it's cool. It's not ... but because it gets stuff done."

I don't know how relational and easy to learn and use it is, but the real issue is are there any non-relational products that are easier to learn and use and get the same things done and if not, why not?

It does not seem to occur to anybody that this might have something to do with whatever relational fidelity its SQL implementation has. And I wonder if Stonebraker, who has lately been pronouncing relational technology obsolete and not up to current needs, and has developed several non-relational products not much heard of, is aware of the irony of his old product's success.

5.
On more than one occasion I criticized the academic substitution of industry fads for scientific research. Instead of leading the industry with science, academics rush to jump on every industry buzzword, a problem which Dijkstra deplored much more intelligently than I can.

Want more evidence? The previous item is one example. Here's another:

Scholarly articles for formal representation of NoSQL

And yet another, better one (detect any irony in the Bio?)

Harnessing Flexible Data in the Cloud

This has an historic precedent: the hierarchic and CODASYL (network) DBMSs were first inferred from existing practices and attempts were post-hoc made to give them a theoretical basis. This effort was subsequently abandoned when it proved too difficult and the result overwhelmingly complex and unusable. Few of today's IT professionals, academics and vendors are aware of this, which is why they are doomed to replicate the past.

6.
In my last update I posted in error on the FP ONLINE page a link to Martijn Evers' blog post instead of the LinkedIn thread that contained my comment on it.

So here is the link to Martijn's post Metadata as a perspective on data and my comment:

I am uncomfortable with the proliferation of concepts and terms at the informal conceptual level that confuse levels of representation, are vague and inconsistent and complexify unnecessarily.

Reality is complex enough without us piling up on it methodological, conceptual and tool complexity--everything should be as simple and parsimonious as possible (but not simpler!). The relational model achieved exactly that at the logical level. The only way to take advantage of it is to reciprocate at the conceptual level. Unnecessary conceptual complexification spills into the logical level and defeats the purpose.