Slashdot Mirror
Fabian Pascal Reacts
Kardamon writes "Fabian Pascal reacts on the recent Slashdot discussion about SQL, XML, and the Relational Database Model, both on DBAzine and on his own web site Database Debunkings. An Open Source implementation of his ideas and those of C.J. Date and Hugh Darwen is REL."
Assuming that a Slashdot 'debate' actually is one.
Can you mod troll/flamebait a whole article?
It's just who he is. Fabian Pascal, Chris Date, Hugh Darwen, and even sometimes Joe Celko (though the rest would likely never admit to it) have good ideas most of the time. But that's the purely academic part of who they are. Fabian reacts hotly to just about anything. Most of his posts on db-debunk are cynical in nature, with little else to offer. When I've tried to get useful clarification out of him, all I got was "read my book, I write so I only have to say anything once." After buying it and reading it thoroughly, I found I still had a question, because he seemed to contradict himself. His answer was, to paraphrase, "I can't convince you if you don't already believe." What a sad answer from an author whose book you're reading, and even worse from someone steeped in "truth", "proof", "logical correctness" and the like!
Communication is breaking down between those who are pretty sure they have a clue, and the rest, and it's not (as they seem to think) entirely the fault of those not in the know. They've given up, they feel they have no reason to try to teach anymore, and that's that. What's worse, there are very few people trying to push their ideas, so when they turn to cynicism, it reflects on their academic work as well. As suggested by Fabian's comments about usernames vs. 'real-world' names, it's hard to divorce the person pushing an idea from the idea itself. But we need to!
There's some good stuff in "the third manifesto", and more to be done. I'm saddened that part of the book is based on what they feel is obvious/established, and part of it is conjecture, but on the whole it presents a fresh look at a not-quite-old-yet idea. We should build on the shoulders of those who came before us, even if they've given up all hope. I hope the slashdot crowd won't give up on this group of researchers just because they can become hot-headed, stubborn, or even flat-out bitter. We've got work to do.
Relational databases aren't enough, either. When you find yourself putting columns of serial numbers in tables so you can link tables together, the relational model isn't fitting the problem.
Clearly, you do not know what a relational database is. You, like many others, are simply the grist for Pascal's mill.
You don't link tables (or relation variables). A relational database management system should give you a rich enough type system so that you can use whatever attributes necessary in a tuple to uniquely identify entities. You should be able to use composite keys without any limitations or worries about space. A good RDBMS would be able to do whatever physical linking and space saving necessary in the physical backend layer to accommodate foreign key relationships with composite keys.
In, many cases when people do this they find that working with composite keys is cumbersome and they blame the relational database. This is kind of interesting phenomenon and conclusion. In fact, it has nothing to do with relational databases (at least in the electronic sense).
The use of surrogate keys long predate electronic data storage systems. Prisons have used numbers for inmates, cars have used license plate numbers, and the SSN was established, long before Codd wrote his seminal papers.
So I don't see what adding columns of serial numbers has to do with a failing of the relational model. The use of "serial" numbers in general has to do with the difficulty of finding good, stable, unique identifiers for entities of interest.
As for times when you NEED tree based data (which is actually less common than most people think). A common mistake is to look at something like an org chart and think that this should be codified as a simple tree, when in reality the tree itself is a physical report that can be derived from more explicit base data. Anyway, I don't see why linking tables can't use the explicit base data in foreign key relationships.
One of the problems of the RDBMS products today and in part the fault of SQL is that "tables" or relvars are WAY to heavyweight. In a true RDBMS a relvar is a fundamental variable much like local variables in a C function. The relvar should be able to referenced in arbitrary expressions with no silly ordered syntax like SQL. Relvar literals should be easy to define in expressions. A "link table" shouldn't be such a heavyweight object in the minds of a database designer. Because of the highly restrictive way SQL works, "Tables" get an overblown status as some kind of special object that makes things like tree data very difficult to work with. This is a failing of the RDBMS products on the market today, not relational model.
Any good RDBMS implementation would have necessary functions to make dealing with tree data easy, or the language would be general enough that they could be defined anyway.
The difference between Fabian Pascal and the truly enlightened is that the while both have come to the same conclusion that the masses are asses, the latter knows there's nothing that can be done about it, and no point in bitching about it either
Actually I do respect Fabian Pascal, and I am not really bashing him for his diatribes. I can't see how his behavior is any more of a waste of time than, say, posting on slashdot. I just hope that he actually ENJOYS running his website and is actually not as wound up as he sounds in his rants. In other words, if he is sort of like a maddox of the data fundamentals world I guess that's a good thing. If he really is this concerned about the state of the world constantly then he really could use some professional therapy or counseling.
Also, Fabian Pascal is way to impatient. The Codd material only came out about 30 or so years ago. That is not a long time for these things to materialize into usage by the mainstream engineering field. Couple this with the fact that the overwhelming perception is that many things in this field are "good enough."