Re: Paper: Database Programming Languages

Hi Derek,

It's end of my lunch break, and I really need to get back my grading work, so I am going to very aggressively zoom in what I think are the main points. I will also not try to fully explain and answer everything, just on trying to make my position clear.

Op woensdag 4 februari 2015 06:44:36 UTC+1 schreef Derek Asirvadem:
> Jan
>
> > On Monday, 2 February 2015 21:47:19 UTC+11, Jan Hidders wrote:
> > Op zondag 1 februari 2015 06:33:40 UTC+1 schreef Derek Asirvadem:
> >
> > > > I would btw. be very curious to know what conclusions your client would think he or she could draw from them.
> > >
> > > Since I have already given you a synopsis, a short chronology, I am not sure what you mean. Would you like a more complete one ?
> >
> > More detail, as in where the devil lives. Because I suspect more is concluded from the paper then is actually warranted and meant by the author. But if we get to that later, that's fine.
>
> You will understand perhaps, that I am restricted due to contract and confidentiality issues.
>
> Sydney. One of the larger Australian banks. From experience, we are much more conservative, and we have much more legislature governing, than American banks. Probably (not sure, from speaking to colleagues) somewhat more than than EU banks. Customer has an app, OO, ORM, all the OO bells and whistles. The data store in in the app, ie. closed architecture, but deployed on MS SQL for convenience (SQL DML, backups). Typical OO monolith, typical OO minus RDB problems. Hundreds of objects have progressed to thousands, a maintence and performance nightmare. Three years of failure, of various kinds, but the most important is lack of data integrity, and every time they install a new version, a whole set of new bugs are exposed. Team leader has a lot of influence, but the auditors gave the business an ultimatum: fix it or shut it down. Second most important: the problems getting the data in/out of the data store, and behind that (really the same problem) lack of Relational Database access. Performance is crap but they are used to it. So they came to me (I had replaced an app+Db in another division in NZ, and the auditors had nice words), and the directive is, replace it with an RDb+App, and teach the team standards, so that they never make these mistakes again. The business has no choice, he doesn't need to get a budget allocated, as it is a risk issue and bank level funds are already allocated. I work for the business, so there is some politics, but I answer to, get everything signed off by, the auditors.
>
> Paper. The Team leader is on his last legs. There is no pressure that he will get fired, but he is dying from loss of credibility. He is adamant that if he adds more complexity to the app, to the objects and classifiers, the app will "work", the bugs will be fixed. They have heard this for three years. This time the difference is, he is making a formal presentation, along with two papers that support his position. I am pretty sure that he got that from his OO groupies, no idea who that is, probably some consulting firm that his wife or brother knows. I say that because the presentation was reasonably professional, while denying all the facts.
>
> This is the typical state of the majority of the OO world: despite the past 100% failures, they will do it better next time, promise. Note that if nothing changes, nothing changes.
>
> DBPL is yours. The central theme of your paper is <read abstract>. He is saying that there is scientific, theoretical, evidence that more complexity deployed in the OO classifier layer will fix the data integrity problems, thus it is his team's fault for not doing that properly, not a problem with the OO/ORM concept (specifically no independent RDb), and he deserves yet another chance.
>
> After a quick consultation as to the veracity of each of his statements, proved to be zero, the auditors have asked me to take the presentation down formally. The business has asked me to do so softly.
>
> Enough ?

Yes, I think so. Very interesting. Many thanks for that.

> Proper Use of Paper

Hard to be completely certain, but I think the answer is a very strong: No. Unless his project was to write a programming or query language for a similar data model and implementing the type inference mechanism in there. That seems unlikely from your description.  

> Here is what he presents (what the whole OO/ORM world uses):
> - the premise of the paper (central theme ?) is that there are data integrity issues that result from (eg) multiple inheritance
> - that such issues can be corrected by increasing the level of complexity in the objects, the classifiers
> - a proof and specific methods are given
> From reading your paper, I cannot say that he (or the OO/ORM crowd) is using it improperly

"Improperly" does not even come close. :-)

> [.... completely unjustified snip ignoring many important issues ....]
>
> > > > What matters is, which objective arguments were put forward to support that interpretation and what the evidence for its merit was. Which interpretation leads to the most effective DBMSs [, RDBs] and what scientific evidence is there for this.
> > >
> > > Note my insertion.
> >
> > Yes, noted. But I disagree with the R there.
>
> What, in this day and age, you give assent to a database that is not Relational ?

I don't exclude the future possibility. That is not the same thing.

> Meanwhile, back at the farm, you are on record (above) as agreeing with specific scientific and architectural principles that the model breaks.

It doesn't. The paper is talking about a certain data model as a logical data model, not as a physical data model. It has nothing to say about how the data is to be stored or even in what type of database.  

> ____
>
> Ok, to summarise your paper. In the context of this thread.
>
> - it acknowledges and supports the OO/ORM+data store model

No. Only as a logical data model.

> - it acknowledges that there are myriad errors in the model
> ___ that data integrity (the tiny bit that you do understand) is broken

No. It looks at how to reason over types and find inconsistencies in schema specifications. Something that happens in any reasonably expressive data modelling language where you can specify integrity constraints. That does not mean that such a language is broken. The opposite could be claimed: if your constraint language is so weak that it cannot express inconsistenties as studied here, it is probably too weak.

> - fails to mention RDBs; the principle of separating Data vs Program, and then dealing with each separately

It doesn't since those are not relevant for the results presented in the paper.

> - the author makes three cardinal errors

The reviewer only one. He completely misunderstands what the paper is about and its relevance within its scientific context.

I would say normally at this point something like "feel free to ask for more clarification" but I'm not sure if I will find the time to answer. :-(

> I can't give you the whole Response, but I can obtain permission and provide a couple of the key pages from it, particularly those with the diagrams that explain the Solution.

I don't think that's necessary. I'm guessing something like a rewrite of the schema where all class combinations are made explicit.

> But first, I hope you don't mind me asking, please confirm that you can /read/ standard IDEF1X data models that we have been using since 1985, and UML classifiers. I am shocked to find out, as evidenced in the Normalisation thread, that many (all ?) theoreticians cannot do that, eg. they cannot read the predicates or the constraints that are in diagrammatic notation, and ask for them to be spelled out in text form.

I don't think that's what they were doing, but yes, I can read IDEF11X and UML Class diagrams. Even taught them for a while to give my student some feeling of how the different notations work and what their differences are.

• Jan Hidders