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."
Oracle et al have spent decades optimizing their products for SQL as they implement it. The chances of a better designed syntax resulting in a faster database is slim. I don't give REL or any other SQL++ contender much chance at this point, if even on the legacy argument alone.
Like most around here I do not reply to news articles often, however the passion of Mr Pascal really has forced me to. Sadly Mr Pascal really does not understand how the medium of /. really works. Before being linked to by /. Mr Pascal doesn't realize that for most of the IT population he was like the rest of us, and probably will end up like that again.. Nobody of importance except in our own minds. As well given the traffic of /. we all realize that he also only received a minor interest compared to many many other posts which received a huge amount of response compared to the piddly 443 replies.
What is worse is that while he preaches his background living through harder times than the rest of us, and relying on his univeristy training making him smarter than the rest of us. He writes or claims to write works of constructive critisim and yet cannot respond to a critique of his work other than paultry name calling (paraphrase)'your all idiots!!'
It is easy as I've shown to critise someone/something, it is difficult to provide suggestions of improvement. May I suggest that before you start name calling you consider how your overly defensive behavior has tarnished your name. /. writes what it writes, virtually unmoderated, no propiganda involved. If your bringing something to the table, consider yourself marginalized.
The main concern of fabian is how a language defined for cross platform syntax representation in general (XML), is used for a model that is, by nature, semantic.
His argument is impecable cause the shortcommings of a subset of XML, made to mimic SQL and SQL mistakes is not really an advancement, except to help close the gap between RDBMS's SQL implementations.
But, there is a language out there that can fully represent the relational model. Its called RDF and a subset of it can be serialized into XML. So maybe the question we should be asking is Is that subset of RDF enough to implement the relational model?
Cause, if it is, then kill XQUERY and use RDF-XML and alas, the best of both worlds (XML ubiquity plus RDF semantic strenght) is what we can use.
NO SIG
The one difference is that the "control" in the US is usually less centralized and the source of control shifts with time.
If you really want to find out about abuses in propaganda, google on George Creel - who probably picked up a few lessons from William Randolph Hearst's conduct just prior to the Spanish American War. I wouldn't be surprised if the Soviets picked up a few tidbits from Creel's work.
It is also interesting that Pascal did not mention Orwell's 1984 which is the classic description of propaganda in action. That story is becoming especially spooky with reports of the UK having the largest scale deployment of public surveillance cameras.
A Shadeless room is a brighter room.
The XML community seems to be largely devoid of any knowledge of history or computer science depth. I have yet to find a description of XML schema processing in terms of grammars and parsers. The brain damaged SAX parser has become popular, while few know about the XmlPullParser. Since many of those who use XML parsers don't seem to have ever parsed anything else, they do not seem to find it odd that the scanner should call the parser, rather than the other way around.
Perhaps this lack of computer science depth is due to the fact that XML grew out of the dot-com bubble, when people felt they had no time to design or think about much. Just get it out the door. It was also during this time that the field was flooded with people who had not necessarily studied computer science.
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."