See series starting at:
The Principle of Orthogonal Database Design Part I
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.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.
--Researchers Identify Anonymous DNA Donors, Wall Street Journal.
The Principle of Orthogonal Database Design Part I
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."This is hardly surprising giving the increasingly blurred line between academia and industry.
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.
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.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.
The paper could have been a one-liner: don't not use the dbms-layer.
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.
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.