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.

Follow @DBDebunk Follow @ThePostWest

See series starting at:

The Principle of Orthogonal Database Design Part I

Follow @DBDebunk Follow @ThePostWest

1.
If the industry spent 10% of its time and effort dedicated to deal with NULLs on understanding and implementing a theoretically sound missing data solution, it would have put a stop to the endless stream of exchanges like the one posted on the LAUGH/CRY? page, from which nothing is ever learned.

2.
A link to an online discussion I participated was posted to the FP ONLINE page.

3.
I have long deplored the "magic wand" fad-to-fad modus operandi of the IT industry: (a) an ad-hoc "new paradigm" that accumulates over time prohibitive problems prompts (b) an ad-hoc "new paradigm" to solve them that accumulates over time prohibitive problems which prompts (c) an ad-hoc... You get the idea. This is a systemic and business culture problem that no individual or organization alone can solve.

Consider the new Quote posted on the QUOTES page in this context.

4.
In all the excitement about the Cloud little thought is given to its nefarious implications. Here's just one:

Genetic information stored anonymously in databases doesn't always stay that way, a new study revealed, prompting a debate on how much privacy participants in scientific research can expect in the Internet era.
--Researchers Identify Anonymous DNA Donors, Wall Street Journal.

The Cloud is a form of outsourcing. Letting others do the work seems attractive if one focuses on expediency and upfront dreams of savings in money and effort and ignores the negatives associated with long-term loss of control. In the context of poor foundation knowledge and ad-hoc tools and practices, loss of control will exacerbate those negatives and defeat the initial purpose.
The Boeing Debacle: Seven Lessons Every CEO Must Learn, Forbes.

5.
Poor foundation knowledge can be addressed only by education. [O]nline courses [may be] inevitable, but that is likely to exacerbate the trend of substituting true education--intellectual development--with occupational training, rather than stop and/or reverse it.

Follow @DBDebunk Follow @ThePostWest

See series starting at:

The Principle of Orthogonal Database Design Part I

Follow @DBDebunk Follow @ThePostWest

1.
A link to my latest All Analytics column was posted on the FP ONLINE page.

2.
A new Quote was posted on the QUOTES page.

3.
A new To Laugh or Cry? item was posted on the LAUGH/CRY? page. Here's a discussion of it. Of course, strictly speaking, our objection is to XML databases/DBMSs. But see if you can figure out what else is wrong with other claims made for it.

4. 
C. J. Date's new book VIEW UPDATING AND RELATIONAL THEORY was added to the recommended books widget on the Home page. Please support this site by ordering via it.

Follow @DBDebunk Follow @ThePostWest

1.
For various reasons I postponed the European tour to the October-December timeframe. Anybody interested in organizing a seminar or presentation, or can put me in touch with somebody who is, please email me. (This applies to the US too).

2.
This week's Quote and Laugh or Cry? item (video) continue the saga of Erik's Meijer ACM article and the letter in response to it by David McGoveran and Chris Date (see Site Update 12/29/12).

Carl Hewitt (in the video) submitted his own letter, Relational Model Considered Obsolete, in response to David's and Date's, defending Meijer's argument. I substituted the link to it, as I could not drop anything from the letter. Here's a discussion of it.

David, who submitted the video, comments:

Carl Hewitt is pushing his trademarked "DirectLogic(TM)" which he asserts "tolerates inconsistency" (i.e., no law of the excluded middle, no proof by contradiction) which he asserts is essential for large systems (e.g., cloud computing). According to him, the relational model is based on logical consistency, so it must go. He asserts that we need a new kind of database built on his DirectLogic(TM) and Actors (his model of highly concurrent computing for which he is famous and which I admire). "Train software engineers to embrace inconsistency" he says! "We have to get over the fact that inconsistency is a bad word."

The esteemed Prof. Hewitt's complaints about the relational model demonstrates his astounding ignorance of it and his recklessness. Every bullet in his CACM letter (a) has nothing to do with, and (b) are not weaknesses of the relational model. (Frankly, it makes me now question my prior opinions of his Actor work. Was it just as bad as this and I simply did not notice?)

Those of us with knowledge of the relational model and real experience in data modeling know every well how to handle inconsistencies - without giving up on the goal of consistency where it is appropriate. Hewitt likes to point to contradictory opinions as an example of inconsistency to be tolerated. Or temporary inconsistencies. We can model these just fine using relational - in fact, trivially. And, by the way, Carl, systems based on the relational model do more with data provenance than any other data model in existence. How does "DirectLogic(TM)" - which "embraces contradictions" - even detect inconsistencies let alone resolve those that can and should be resolved? Is its data provenance contradictory too?

"Tolerating inconsistencies by designing the logic underlying your systems to permit it"? That's just insane! Anyone who has built a real-time control system (think defibrillator, aircraft flight control, nuclear power plant, or crane operations at a port) knows this. The suggestion that the financial industry (banks, trading systems, etc.) should ever permit inconsistent transactions is simply absurd. I sure don't want these people touching (let alone building) the systems I depend on for life, safety, money management, etc. If Hewitt, Meijer, et al are the new architects of cloud computing, then maybe the new name for cloud computing should be "#@!* in the sky" computing! Ever hear of GIGO, Carl?

I think by large systems Meijer and Hewitt think Google, Facebook, Twitter, Zynga and the like, but they really don't realize it. The damage from inconsistencies in their software causes little damage. They simply cater to the spreading delusion that emulating the software of these companies -- which already exhibit serious problems--they will be as successful as them, no matter what their business is and what is the value of data for it.

This is hardly surprising giving the increasingly blurred line between academia and industry.

3.
Speaking of which, Toon Koppelaars writes:

Academia first created the problem, by advocating all logic be removed from the dbms-layer. And now they come up with research to fix that.

• StatusQuo: Making Familiar Abstractions Perform Using Program Analysis
• StatusQuo: Automatically Refactoring Database Applications for Performance

The paper could have been a one-liner: don't not use the dbms-layer.

This is such a profitable business that is SOP in the IT industry. The academia, which is increasingly just a branch of the industry, has caught up. To get funded for research with such results--it's good work if you can get it.

It's been a while since I predicted that we are going back to the apps+files days. Almost everything that's happening is some aspect of that.

3.
An interesting and not unrelated LinkedIn discussion: Software Structural Erosion The Shame, The Heartbreak & The Cost. Which explains the following from a friend in response to my reluctance to upgrade to the latest Word version:

I can guarantee that you will hate the UI of the new version. It needs a huge screen to be usable. I like to work split screen as I have to do a lot of comparison between text and website which is why I have a 2560 x 1650 monster here. Word is just about usable in half of the screen but at my customers with slightly less screen real estate it's no longer possible. Resizing a GUI so that the toolbar works but text occupies only a third of  the screen says an awful lot about software development over the last ten years.

It's probably better for Dijkstra that he did not live to see all this, which he predicted.

Follow @DBDebunk Follow @ThePostWest

1.
A new Quote of the Week, by two MIT professors, no less, was posted on the QUOTES page. If you believe the second paragraph, I have a bridge in Brooklyn to sell you. Read the whole article that puts the hype in perspective for a reality check.

Apropos which, more validation of the deterioration of education:

Don't Let Math Pull the Wool Over Your Eyes


2.
A new To Laugh or Cry? item was posted on the LAUGH/CRY? page. A good example of howone becomes a database professional.

3.Sima Ilic (via email): 

I had the opportunity to play with SIRA_PRISE for the past month or so and it's a fantastic TRDBMS. In my opinion it deserves to be mentioned as a TRDBMS software on DBDebunk.