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.
To begin with, it's a TRDBMS:
- no NULLsI'm ashamed to admit that I was unaware of it, but I have an excuse: I was out of the field during 2006-2010, when it was developed. Here's the designer's thoughts on it, but can't resist quoting the conclusion:
- no column or row ordering
- no nameless columns
- relationally complete language
- clean separation of logical and physical design
- has it's own physical storage mechanism, ie. does not rely on an SQL (R)DBMS
The rest is a matter of taste and I really liked it:
- unique attribute names in the entire database
- prefix notation for operators
- mandatory specification of type for literal value selectors
From doing this project, I have learned a couple of things that I would like to present as a conclusion to this small chapter :Knowing Erwin, I know I can safely recommend that if you want to get a sense of what a TRDBMS looks like, you check it out. But be forwarned: you better be comfortable with formalisms in general and relational algebra in particular (Erwin provides an introduction).
- Contrary to common and popular belief, the relational model of data is indeed implementable. In full, without perversions, or ugly compromises and without any additions needed to suit users' data management needs.
- This holds in particular for the definition of database constraints of arbitrary complexity, which will allow DBMS users to effectively delegate to the DBMS the enforcement of every single business rule they have, without having to write down one single byte of (imperative) program code to achieve such enforcement.
- Management of temporal data (aka "historical data") is doable, and this without running into the "ugliness" of typical SQL-based systems trying to do exactly that (the most devastating characteristic of such solutions probably being the sheer textual length of the query expressions needed to get something out of the database, as well as of the constraint expressions viz. program code needed to prevent nonsense from getting into the database).
- Vertical decomposition in the logical design of the database is perfectly doable, provided your DBMS offers sufficient options in the area of the physical design of the database to design away (at the physical level, where it belongs) any possible devastating effects on the performance of the system. It should not come as a surprise that the second and third item in this list identify precisely the areas of data management where I believe SIRA_PRISE truly excels, and where the great potential lies for this system, or any other one that resembles it.
_____________________________________________
[1] If you think I must be quite some arrogant bastard to think I do better than what entire armies of programmers at the best-paying companies have been able to achieve, I can only respond with two observations : (a) those armies started developing more than 30 years ago, and have missed on all the additional knowledge and insight that has surfaced during the last decades (or they were not at freedom to implement new ideas because they were bound by backward compatibility issues and such), and (b) there is some truth too in the dictum that "one man can do in one day what two men can do in two" (and the count doesn't stop there).
I have added SIRA_PRISE to the TRDBMS list on the home page.
Do you like this post? Please link back to this article by copying one of the codes below.
URL: HTML link code: BB (forum) link code:
I first noticed this on Lambda the Ultimate: http://lambda-the-ultimate.org/node/4667
ReplyDeleteWhich lead me to this absurd rant: https://docs.google.com/file/d/0B79uetkQ_hCKb2xHb0QtZi1rYkk/edit
I have to ask: have people like this ever done 'actual' work where their salary was dependent on the ability to produce value for their employer? I must confess to largely being self-taught (which is why I consider fundamentals and science to be a better use of my time than cookbook recipes (how often have I seen even the nominally 'educated' apply forms that they only vaguely understood for purposes to which they were ill-suited.)) I actually have a great deal of sympathy for this guy's work because I've long been fascinated by Prolog because you can use it to "declare" a set of facts and thus derive them from a variable world. What follows are my reasons for asking the first question:
Inexpressiveness: Is relational algebra the same as SQL the language?
Inconsistency non-robustness: I've dealt with this many times by building a consistent data model for actual data and a way for users to track and fix the inconsistent half-truths that reality flings at them. What alternative is being proposed?
Information loss: (The only databases I've seen purged of information are the ones that were so badly designed that the 'information' was discovered be inaccessible gobbledygook.)
Lack of provenance: Several vendors have tried to address this in an automatic fashion but nothing in relational algebra prevents the diligent worker from doing this by design. (Interested to see the SIRA_PRISE solution.)
Inadequate performance and modularity: There you go again! The Holy Cow of Performance justifies more absurdities than an Improbability Drive ever could! Actual experience with 'living' programming languages would show you that performance is really a factor of how much time and effort is spent improving the underlying code (up to the point where it cannot really be improved.) In every language I've ever programmed later versions had better performance than earlier ones without changing my code. (Not to say I didn't have to change code because of system changes or because of actual language changes but those were never the big improvement that a new compiler or interpreter was.)
There is no practical way to repair the Relational Model to remove these limitations. (There is no nice way to say how stupid this whole letter is. I am truly sorry that I have to put it that way.)
It may be that we still just a bunch of monkeys sitting around bashing rocks with bones. (I hope not.)
I'm afraid that they probably did actual work, but they probably worked in "cookbook mode" and have very distorted notions of what theory and models are. When I encounter this sort of thing I ask only one question: What do you replace predicate logic and set theory with, that addresses all these "problems" with the RM and is superior to it? What is the structure, manipulation and integrity features--PRECISELY, please--and what theoretical foundation underlies it? That's enough to make them disappear, because they usually dk what I am talking about.
DeleteI will have to review the two links and descide whether they are worthy of debunking, or used for quotes/laughcry.
It was already debunked. The PDF is a letter of recommendation for the Meijer article.
DeleteYes, but my debunking is usually different.
DeleteThis Hewitt guy sounds like a broken record. Every time somebody point out his misunderstanding of RM and his mistakes, he regurgitates a few sentences without addressing them.
DeleteActors model my foot. He has no clue what a data nodel is.
Laughcry it is.
My intent was to point out the the appearance on Lambda the Ultimate. I realized the original article was already addressed here. I guess if you notice these pests then they are always underfoot.
ReplyDelete