Follow @DBDebunk Follow @ThePostWest

WS writes:

On the subject of object orientation I often feel inclined to quote Leslie Lamport's comment in the introduction to his book "Specifying Systems": "If exposure to C++ hasn't completely destroyed your ability to think logically, you should have no trouble filling in the gaps in your mathematics education".

I tried for many years to understand OO, but without success. It didn't occur to me until I encountered the material on dbdebunk that the problem might not lie with me. OO's lack of a formal definition leads, I think inevitably, to what I have come to call PALC (Pointless Additional Layers of Complexity). Every addition to OO leads to new problems that require ever more complicated solutions, that in turn create a whole new set of problems.

Lack of a theoretical foundation tends to produce fuzziness.

I once wrote an article called "OO for Application Development, Not Database Management". As far as I understand it, OO is essentially a set of informal guidelines that, if followed, purportedly results in programs that have certain beneficial characteristics.
From a database perspective about the only OO aspect that has any relevance is type inheritance and that is an issue orthogonal to the data model. But it is common for the industry to extend anything to everything--that's one source of fads.

As to increasing complexity, as I wrote in the introduction to one of my earlier books, there is an economic incentive for it: simplicity does not require so much training, so many consultants, so many books. Which explains some of the rejection of Codd and the relational model.

It was my feeling that XML made no sense whatsoever that led me to search for other sceptical voices, which is how I found dbdebunk in the first place.

XML is an excellent example. Insofar as database management is concerned, its inventors initially claimed that it is purely syntax and for data exchange between computers. But then what difference does the content of the tags make when computers are semantically blind?

Discussions with Java programmers on logic tend to reveal the fact that they don't understand what logic is. For example they insist that there should be "no logic in the database". However on closer questioning they reveal that views are allowed but stored procedures are not - which is strange as there is obviously nothing whatsoever procedural about logic.

It's not just Java programmers. Database professionals don't either. Consider the implications of this given that logic is the very foundation of database management. But this is not entirely their fault--the education system failed them. How many IT professionals go through a logic course?

The other argument I come across is that logic is "too difficult" or "too complicated". I would say one of the great strengths of the relational model is that the mathematics behind it is not very difficult. The principles can be grasped quickly though I would say using them properly (as with anything) requires a lot of practice.

An important point to understand is that the usefulness of the relational model for database management comes not just from math, but from the equivalence of set theory to predicate logic. The relational structure (R-tables) and operations (relational algebra) are relatively easy to understand. But as Erwin Smout points out, without some familiarity with logic, queries and integrity constraints of arbitrary complexity can be quite difficult to specify. And then you have to contend with the data language implementation.

To finish on a more positive note, I have been able to persuade some of my immediate colleagues of the importance of fundamentals; with the rest of the company I suspect it is a hopeless struggle.

But of course: after all, they did not take my courses. :)