Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Databases Programming Software

Fabian Pascal Reacts 161

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."
This discussion has been archived. No new comments can be posted.

Fabian Pascal Reacts

Comments Filter:
  • by k98sven ( 324383 ) on Monday September 06, 2004 @01:33PM (#10169775) Journal
    Assuming that a Slashdot 'debate' actually is one.

    • This post isn't funny. I mean what? This guy actually thinks that he needs to defend himself against posts made by ignoramuses on Slashdot? Given my distruct of both XML and SQL - hell anything that doesnt have a nice binary API - I was quite willing to belive him, but this bizarre behaviour has made me categorize him firmly as a loon.
    • by Anonymous Coward
      Shouldn't it be "RINS"?? That's what it says on the web site: "Rens Is Not Sql".
  • by iota ( 527 ) * on Monday September 06, 2004 @01:40PM (#10169816) Homepage
    Okay Fabian needs to relax. Take a deep breath! He made two fundamental mistakes which probably cost him to waste time he could have spent on something more productive, or at least personally gratifying... (Although bitching about Slashdot posts can be gratifying, I suppose.)

    1. He took Slashdot comments personally. This is something we see all the time. Let this serve as /another/ warning to all future Slashdotees -- People hidden behind anonymity, even experienced onces, like drivers, will forget that there are real people on the other side of the conversation.

    2. He treats Slashdot comments as well-thought responses to his articles. For Pete's sake come on! This is the place where professionals, interested parties, and random wannabes can foam at the mouth and say the first thing that comes to mind. Hell man, comments are moderated by popular vote! This is not exactly a medium of high academic quality. And that's just fine. Sometimes first impressions are what you want, sometimes they're complete BS, but they only give you an insight in to where some people would /start/ thinking about a problem, not where they would end up after careful consideration after research and practice.

    In the end Fabian, you're probably gonna get flamed for your response as well. If you want it for the intention, cool. If not you should probably just let it go...

    • by wolenczak ( 517857 ) <paco@cot e r a .org> on Monday September 06, 2004 @01:50PM (#10169871) Homepage
      Can you mod troll/flamebait a whole article?
    • by Unordained ( 262962 ) <unordained_slashdotNOSPAM@csmaster.org> on Monday September 06, 2004 @02:03PM (#10169954)
      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.
      • ...it seems like the researchers have forgotton the "simple" part of SQL.

        I guess they've decided that it's time to cut off the face to spite the nose with SQL. Instead of fixing or improving SQL, they want to get rid of it, because it's not "pure enough"?

        Doesn't make sense. SQL works good enough.

        At least with OCL, it is almost possible to map it in my mind to something I know well.
        • by Unordained ( 262962 ) <unordained_slashdotNOSPAM@csmaster.org> on Monday September 06, 2004 @05:01PM (#10171153)
          "SQL" didn't stand for anything at first, and now has several meanings of which 'simple' is one, 'structured' is another, etc. And if you use SQL a lot, you can find that it's anything but simple, particularly when it doesn't natively do what you need it to do. A few paragraphs of ugly joins, sub-queries, NULL-handling, and temp tables later, and you begin to realize that what you're doing could probably be done more easily by the server, if only it knew what you wanted -- but your language doesn't allow you to accurately express what you actually want, limiting you to a simple vocabulary.

          There's a point at which you stop fixing something up, and just go ahead and replace it. Mistakes happen. Some of these guys were involved in the SQL specs the first time around, it's not like they never wanted to have anything to do with it.

          As far as they're concerned, it's like a bunch of people thinking that math goes as far as their 4-function calculator, which is "good enough" for them. It is good enough, yes, for some people, but others want much more, and want a good way to express what they want. Symbolic math, symbolic relational operations, it's all the same idea. (Relational databases are firmly grounded in mathematics, it's not a stretch at all to use this simile.) The new language they propose (as an example only, not as a final product) isn't particularly hard to read and understand, but is much more expressive when you need it to be. You can do 6*8 using nothing but the '6', '8', and '+' keys, but wouldn't it be easier if they just gave you a '*' key, and while they're at it, made it easier to extend your calculator for new operators too?

          There's a good whole chapter in "the third manifesto" concerned with mapping the current SQL language to the "D" language they propose; they don't want to force you to switch over without some time to learn, and they'd like to keep existing applications working on new server software as much as possible. Yes, they want to replace SQL, but want to give you a migration plan too. (Note, however, that the cost of using this SQL translation feature would be the same, more or less, as trying to switch to a different dbms vendor -- not all SQL is the same! Identical syntax can even give you different results on different servers!)
        • SQL is very bad. It's just better than the working alternatives.

          I don't really think that SQL can be improved into something good, only into something better. I'm not about to cast aspersions on someone who's trying to do something good, rather than just improve on the current mess.

          N.B.: I'm no SQL guru. I use it when and as I must. And I find it in many ways terrible, but especially when I try to map it onto an object class. BLOBs are essentially giving up on the hope of getting SQL to work as you
    • 1. He took Slashdot comments personally.

      No, not really. What he did was point out Slashdot comments that were personal and noted that these represented the majority.

      Sometimes I too find myself getting tired of explaining the difference between "You're stupid" and "Your idea is stupid" just to try to have a meaningful exchange. It's particularly bothersome when the other person is in a position where knowledge of that difference legitimately ought to be assumed.

      2. He treats Slashdot comments as well-tho
      1. See John Gabriel's Greater Internet Fuckwad theory. [penny-arcade.com]
      2. Yup. We slashdotters think off the top of our heads!
    • Hell man, comments are moderated by popular vote!

      Far from it. Despite what Slashdot editors may tell you, many people have been barred from moderating without cause. I myself have not been given the opportunity to moderate in over a year, despite a high karma and regular metamoderation.
  • by grylnsmn ( 460178 ) on Monday September 06, 2004 @01:42PM (#10169826)
    I stopped reading and only skimmed the article after I read this:
    Note: Participants in the thread use aliases rather than real names. So much for the courage of their convictions.
    I'm sorry, but the use of an alias or username doesn't say anything about the "courage of their convictions". It is a common practice to use an account name, if only to provide a unique identifier for a user.

    For example, I've done a search on Google for my own name, and found that there are several other people in the US who share my name. One is a preacher in Florida. Another is a lawyer in Pennsylvania. I don't even have all that common of a name.

    What about my cousin, named David Evans? Evans is a common last name (at least for those of Welsh extraction), and david isn't exactly a rare first name. How many "David Evans" might post at a site as popular as Slashdot?

    I'm sorry, but to dismiss someone (and their arguments) as cowardly because they use a screen name or user account is to ignore the substance of their remarks. If he were really interested in accepting constructive criticism and improving his ideas, he would not be ridiculing those who comment on them.

    • by jackb_guppy ( 204733 ) on Monday September 06, 2004 @01:54PM (#10169899)
      Shoot he should understand an alias! What is really an userid in a database, huh? ;-o

      PS: Database Debunk... I do not see debunking, just pushing to buy a book or two.
    • by bladernr ( 683269 ) on Monday September 06, 2004 @02:02PM (#10169948)
      I'm sorry, but to dismiss someone (and their arguments) as cowardly because they use a screen name or user account is to ignore the substance of their remarks.

      Is he entirely wrong? Hiding behind the screen name - and I do hide, you will not find my real name, address, and phone number in my /. journal - removes some accountability. As soon as you remove accountability, people will do and say things they wouldn't if they were accountable.

      I do write articles in print media under my real name. I check facts, think things through, cite sources, interview experts, and all the other sorts of things you do when your reputation is on the line (accountability). During the course of this research, I discover that I don't know everything, and the quality of the articles is much higher because of the research (and the research happens to a large extent because of accountability).

      Now, here on Slashdot, I am free to say whatever comes to mind, as we all are. How many things have been stated as absolute fact that a quick bit of research would show are false? How many people would shoot off at the mouth with so little thought if the comments would be associated with them, personally, throughout their life?

      Being able to speak anonyously is a good thing for political reasons (dissonants in China and the Middle East don't enjoy the same freedoms we do in the West, so I don't fault them for remaining anonymous or using aliases in commentary). However, any time someone is speaking anonymously, what's wrong with being a bit more suspicious of what they say?

      • Now, here on Slashdot, I am free to say whatever comes to mind, as we all are. How many things have been stated as absolute fact that a quick bit of research would show are false? How many people would shoot off at the mouth with so little thought if the comments would be associated with them, personally, throughout their life?

        How many print articles contain inaccurate information as well? One example comes from this past week, where the AP reported that the crowed "booed" when Bush made remarks about Cli

        • Another example? Every single time I've been able to check on a media story they've either lied, gotten it wrong, or so distorted the event that I didn't recognize it (without significant effort, as in "I was in the same area at the same time, so they must be talking about the same thing").

          Also, authors regularlly use their position of relative power/invulnerability to expound positions that they would never dare in front of a hostile crowd (to be fair, some of them WOULD dare, and became authors out of a
    • Exactly right. Anonymous writings can even sometimes be more effective that signed writings because you are not reading them with some preconceived notion of who the author is and what his/her biases are. However, this only holds as long as the piece sticks to independently verifiable evidence and reasoned argument. Anonymous allegations with no proof or simple personal invective may be safely ignored. But simply dismissing one's opponent solely on the basis of anonymity (or, more often at Slashdot psed
    • Bottom Line: he signs his name to his opinions.

      "Anonymous Cowards" don't - that's why they are labeled "Anonymous Cowards", right?

      I use a handle - and put my name at the bottom.

      "Anonymous Cowards" can't, apparently.

  • by mondoterrifico ( 317567 ) on Monday September 06, 2004 @01:46PM (#10169851) Journal
    and can summarize it for you.
    He basically makes the point that everyone on slashdot is a clueless twit.
    A very wise man indeed. :)
    • I don't think you need to be wise to find that out.
    • by pubjames ( 468013 ) on Monday September 06, 2004 @02:00PM (#10169930)

      I also read the article. My summary is as follows:

      Fabian Pascal is a twit.

    • Ironically, let's summarize for those herein who won't RTFA...

      What is really astounding is not just the almost total lack of knowledge by practitioners, experts, and even academics, of the history and foundation of their own field (which does not stop them from making broad pronouncements; they even boast about it; Unskilled and Unaware of It indeed). Rather, it's also the lack of most basic reasoning ability--confusion, vagueness, inconsistency and a total disregard for evidence. In my writings I at leas

  • by toupsie ( 88295 ) on Monday September 06, 2004 @01:46PM (#10169852) Homepage
    Unlike chocolate and peanut butter, these are two things do not go together. Nothing destroys a really good technical discussion than an introductory quote of Chomsky. I don't care if you love Reagan or Kennedy gets you feeling all squiggly inside, its just wrong. Plain wrong. Stick with the tech you know and keep it away from what you think is the right political belief.

    also ignore my .sig

  • Skills (Score:3, Funny)

    by unlocked ( 305145 ) on Monday September 06, 2004 @01:53PM (#10169894) Homepage
    Mr. Pascal seems to be quite the cunning-linguist.
  • by Ars-Fartsica ( 166957 ) on Monday September 06, 2004 @01:54PM (#10169898)
    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.
    • I agree. People are trying to re-invent the wheel without knowing that the wheel even exists yet. When I read articles about an XML query language, I just have to shake my head and laugh. If most developers understood RDBMS', we wouldn't even be having this discussion.
      • To clarify your statement, are you saying that, because you can bodge your RDBMS into returning hierarchically-structured information, there is no reason to look for a more domain-specific abstraction?

        Why use one line of code when you can use 20, that kind of thing?

        Just checking.
    • by Anonymous Coward
      Not true. It quite possible to create a product that would "out-perform" Oracle if that was the only criteria. The management system that supports a database product is just as important.

      SQL has many flaws that are inherent in the language, and those flaws can manifest themselves as bugs. SQL is an old language, just like C. Unfortunately vendors make money by selling backward compatability, XML capabilities etc.

      I think Pascal's point is that (1) many people are ignorant (not even aware of the problems) a
      • Not true. It quite possible to create a product that would "out-perform" Oracle if that was the only criteria.

        If you think you can build a product that meets all of the requirements that Oracle does, yet performs better in the average case...well, I call BS. Don't respond with MySQL performing better because by admission MySQL does not meet the same requirements as Oracle.

    • Oracle et al have spent decades optimizing their products for SQL as they implement it

      SQL should not be "as implemented by x or y". And decades of optimization is perhaps not the best. Decades ago, RAM was much more costly. Datatype where usually much poorer(even if I have problem with the principle ofBLOBs).

      Premature optimization is the root of all evil (it's not from me ;). Sound mathematical principles, without shortcuts and exceptions, seem much more interresting in the long run.

    • by wfberg ( 24378 ) on Monday September 06, 2004 @02:24PM (#10170096)
      kx [kx.com] have an interesting product.. 10-100x as fast as you "legacy " database, by which they mean oracle et al of course, and specialized for time-series (which is a big deal if you deal with those).

      I don't think oracle is quite the fastest general-purpose SQL(semi)compliant RDBMS there is - it trades speed in favor of integrity.

      Also, if databases were ueber-efficient at executing SQL queries, there'd be no great need to use server side stored procedures to speed things up.

      And, last time I checked, google didn't run oracle, and for a reason.
      • I don't think oracle is quite the fastest general-purpose SQL(semi)compliant RDBMS there is - it trades speed in favor of integrity.

        According to some TPC benchmarks, Oracle is in fact the fastest.

        • I don't think oracle is quite the fastest general-purpose SQL(semi)compliant RDBMS there is - it trades speed in favor of integrity.

          According to some TPC benchmarks, Oracle is in fact the fastest.


          Benchmarks, schmenchmarks. Does Oracle's license even permit publishing your own benchmarks?
      • Kx's database is column-based instead of row based. That makes it hugely efficient for some queries (which tradition row-based RDBMSs have trouble with) and incredibly bad at others (in which traditional RDBMSs shine). It's just a question of trade-offs.

        Also, if databases were ueber-efficient at executing SQL queries, there'd be no great need to use server side stored procedures to speed things up.

        I think you've misunderstood something. The idea behind Stored Procedures is that you offload the data proc

        • Kx's database is column-based instead of row based. That makes it hugely efficient for some queries (which tradition row-based RDBMSs have trouble with) and incredibly bad at others (in which traditional RDBMSs shine). It's just a question of trade-offs.

          Well, that's one major Kx feature, yeah. It's a bit more than just that, from reading the description.

          Kx isn't the first column-based database, either. Sybase's IQ [sybase.com] product (formerly IQ-Multiplex) has been out for years now, with the exact same tens-

    • The goal of better syntax is not faster databases. Run time performance is not always the primary aim. The goal of better syntax is faster, easier, and more reliable development, and provably (within reason) correct data management code. For the PHB, that means cheaper development and maintenance.

      As for "REL [sic] or any other SQL++ contender" not having much chance, you're right. But I remember when "not much chance" was the typical response of IT directors when asked if they'd ever give up greenscre

    • The chances of a better designed syntax resulting in a faster database is slim.

      That is most certainly wrong: by using a more expressive syntax, you are able to convey more exactly what it is you are requesting, and thereby enable the database to optimize better.

      Case in point: hierarchical relations. (Standard) SQL does not allow you to retrieve a list of nodes in a tree, so you have to emulate that query by issuing multiple queries in your application, in some stored procedure, etc. If SQL had proper supp

      • That is most certainly wrong: by using a more expressive syntax, you are able to convey more exactly what it is you are requesting, and thereby enable the database to optimize better.

        But any company going this route would have to basically start over again and forsake the decades+ optimization made to the current model. I doubt they would be able to produce a better performing product, although I grant you this is a conjecture.

        • You're both wrong. Optimisation is not dependent on syntax, it is ultimately dependent on the semantics encoded in the syntax. The same semantics (say, that of the relational model) may be expressed in innumerable languages. Obviously, some of these languages will be more expressive than others, but all (in theory) will result in the same run time performance. They will not, however, result in the same developer performance or ease of maintenance.
      • You can use left-right trees to do hierarchies quite well in SQL, and query them quite efficiently, both up and down the tree, as well as across the tree.

        The main drawbacks, at least in current RDBMS, is updating the tree table as new nodes are added. Adding the nodes isn't the problem, incrementing node "pointer" values gets expensive.

        Oh, and a lack of native support in SQL for them means you're writing stored procs and triggers to maintain them.

        Joe Celko talks well about L-R trees in SQL in the "DBMS M
    • In in the last stages of a project that implemented a graph based query language for a graph that is implemented by an Oracle database. Our query language eventually results in some large SQL statements and on occasion the Oracle optimizer does pretty poorly at executing these queries. My colleague, who is an Oracle expert, has added a large number of "hints" to get the optimizer to do "the right thing". These "hints" can result in a factor of ten reduction in query time.

      Lots of work undoubtedly has

    • You can't optimise queries that you can't express in SQL, so you end up avoiding simple operations in favor of complex ones that happen to fit into the syntax.

      For example, there's no update-or-insert operation in the standard, so half the database vendors out there add it as an extension, and half argue that you shouldn't do an update instead of an insert anyway. Meanwhile you play games with temporary tables to make your updates fast enough. Maybe.

      Whether there's enough of these cases to make a differenc
  • I agree (Score:4, Insightful)

    by DogDude ( 805747 ) on Monday September 06, 2004 @01:58PM (#10169925)
    While this "article" is rambling, and realtively incoherent, I will agree with him on one thing: the average Slashdot user knows *nothing* about data. Any time a database discussion crops up, every PHP and PERL hack comes out of the woorkwork describing the wonderful spped at which MySQL handles a "select *" query. I personally feel that any database that is large enough or complex enough to have a DBA should limit access to it to only people who have had a basic "what is a database" class that explains what a relational database is, how it works, the basic history behind it, and specific basics such as stored procedures, triggers, views, foreign keys, etc. I can't begin to count the number of completely ignorant postings I've seen on /. regarding data. Hell, most people treat the database as an afterthought when designing an application, when, in reality, it should almost always be the *first* consideration.
    • I'll admit, I cut my first databases in MySQL with a php front end. But I've moved on since then and I have to agree with the parent of the parent poster.

      Learning how to properly design & use a DB is not an easy job, and most people do it ass-backwards wrong, especially those versed in the Php-MySQL mindset.

      That is not a healthy mindset for developing a mission critical system, and I would hope that anyone consider it would realise this.

      Lets put it this way:
      Would you hire a developer who didn't under
      • by Anonymous Coward
        Its the same for a DB design who doesn't use forieng keys, or views, or constraints.

        Foreign keys and constraints, sure, but I don't see the amazing cant-live-without usefulness of views... they're basically just stored queries, and if your frontend is generating the SQL (i.e: it's not you typing it in every day), how is a view really all that useful?
    • Hell, most people treat the database as an afterthought when designing an application, when, in reality, it should almost always be the *first* consideration.

      My boss being one of those that can't understand data. Even though I did not finish college, I did at least finish my database classes. When designing a data driven web site I always study the data that is to be stored before anything else. What most programmers forget is that these web sites are *DATA* driven. Without good, clearly organized da
    • Hell, most people treat the database as an afterthought when designing an application, when, in reality, it should almost always be the *first* consideration.

      Right on. The database is the foundation. Poor choices in your database design can result in terrible complications when you attempt to support, maintain or upgrade an application. If you build a house on a shitty, out of shape foundation, how long do you think the house will stand? How easy will it be to add on to the house?

      MS Access is the wors
    • Hell, most people treat the database as an afterthought when designing an application, when, in reality, it should almost always be the *first* consideration.

      Actually, the problem domain and user requirements should be the first consideration. You shouldn't even think about the database until you have a domain model...

  • by Vthornheart ( 745224 ) on Monday September 06, 2004 @02:10PM (#10169991)
    When someone calls you a Communist in a dismissive manner on a bulletin board, that signifies that you have won the argument. It's a variant of the classic "Comparison to Nazis/Hitler" BBS rule. The people arguing against Paschal unleashed the dirty C word on him as their defense, hence they lost the argument. There's no need to defend yourself against it! =)
  • So what? (Score:4, Insightful)

    by ljavelin ( 41345 ) on Monday September 06, 2004 @02:15PM (#10170023)
    Heck, everyone knows that SQL was a mistake and that XML was an even bigger mistake. Merging the two seems like compounding both mistakes.

    And, at the same time, most of us know that SQL and XML are pretty good at something, and it'll be a long while before someone develops a compelling alternative.

    So the news here is that Fabian Pascal doesn't like some ideas, and to be honest, I don't like some ideas too. He doesn't have to provide alternatives to unloved ideas. I think that's OK.

    I worked with a woman who was damned sure that she was going to store a copy of my relational database (Postgres) in her XML database. It sounded like a bad technical idea. I didn't like it, and I expressed that I didn't like it without proposing an alternative that would work with her application. Isn't that OK?

    • If Fabian is talking to the world at large, he should back up his complaints with constructive proposals. It's a complete waste of bandwidth to throw around a lot of complaints without putting those complaints into a context of how life might be someday improved. I read Fabian's original screed without learning anything solid I could take away as a perspective on SQL's weaknesses. I didn't notice a link to the REL project last time around, but this time when I looked at REL as least I came away with some
  • I was born in one of the harshest members of the Soviet bloc and lived?if you can call that living--there until I was 13. When emigration was permitted, anybody who could, fled, including our large and close extended family. We scattered all over the world and lost contact and everything we had.

    Poor him. Just because he lived in communist country (I could imagine worse than that, say -- Poland under NAZI occupation), doesn't mean he has to be right in a technical question. Why does he bring this up at th
    • Not necessarily true. As someone who lives in China, I can tell you that most of the horror stories people hear about the 'evil commies' are wildly out of context. And I easily roll my eyes at all the American's who run around talking about the "freedom" they have.

      Granted that at higher levels of intellectual discourse regarding social and economic systems, you aren't more informed. But it's alot easier to identify the propaganda being fed down your throat in America if you weren't fed it from birth to cur
    • Moreover, I don't understand what it has to do with debunking databases. I looked through the site and couldn't find much information related to database debunking - well, other than books or reports I was expected to pay for.

      Yeah right, I'll pay money to see someone rant against common industry practice... NOT.

      The way he uses indentation to show different contexts is also rather confusing. Fortunately I don't care enough to actually want to understand his point. Good thing too - I might have had troubl

    • Re:Poor Fabian (Score:3, Insightful)

      by Freon115 ( 672518 )
      Did you even bother reading his article and the previous discussion?
      He mentions his origins because that's what stupid slashdotters attacked him on last time.
    • Re:Poor Fabian (Score:4, Insightful)

      by MemoryDragon ( 544441 ) on Monday September 06, 2004 @04:52PM (#10171081)
      Arr somebody mentioned, he came from romania. I have not grown up in a socialist country (unless you agree with good ole Arnold the Governator, actually living here was more free than in many other countries)

      But giving the almost non existend distance I already met a bunch of romanian people. Believe me if you made it up to the age of 13 you probably had a harder life than most people up until the age of 65 in other countries. The country really was fucked up in many regards, with a totalitarian neo Cesar on top of it. If there ever was a European big brother like country, probably Romania would have deserved the title.

      But back to the other quote, have you ever spent a a thought about following that in the US you constantly here how good this country is, that it is the best to live in the world at least ten times a day in variations, no matter how f**** things are. Probably the guys in Vietnam and noq Iraq hear/heard it also every day on the US radio, television etc... while bleeding to death in the sand / or were bleeding to death in the jungle.

      Great that the government and the country is so great, while the government has a serious pribe problem, with legalized bibe with the face of electional donations etc... Given this guy is heavily sensitive to this issues, I am glad he speaks out openly.
  • RDF (Score:3, Interesting)

    by alexborges ( 313924 ) on Monday September 06, 2004 @02:22PM (#10170076)
    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.

  • by Animats ( 122034 ) on Monday September 06, 2004 @02:35PM (#10170170) Homepage
    That article is just a long flame.

    There are real issues, but the article doesn't address them.

    Tree-based databases are thirty years old. See MUMPS. Explictly linked databases are also thirty years old. See the CODASYL DBMS. XML database enthusiasts need to read up on those old systems to avoid making the same mistakes.

    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.

    These issues are not being addressed all that well.

    • by wintermute42 ( 710554 ) on Monday September 06, 2004 @03:02PM (#10170329) Homepage

      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.

      • > I have yet to find a description of XML schema processing in terms of grammars and parsers.

        You are seriously joking, yes? Read anything about RELAX NG for a start. Look at programs like relaxer and other Schema compiler compilers. RELAX NG was based on Tree Automata from day one.
        • A fair criticism. However, the sad truth as far as I can tell is that Relax NG will be an also ran. XML Schemas seem to have become the standard and I have not seen any formal defintion for how a schema defines an XML document. That is, does a schema define an LL(1), and LR(1) or a backtracking tree match (which seems to be the case).

          So, yes, not everyone is clueless. But what seems to be the accepted standard does appear to have been developed by the clueless.

      • 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.

        Hedge automata: a formal model for XML schemata [psu.edu]

        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

    • by Anonymous Coward on Monday September 06, 2004 @04:28PM (#10170911)

      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."
    • by Anonymous Coward
      Most tables HAVE a primary key in them somewhere. It is just a matter of getting the data in there or making sure it is designed correctly. Why put a monotomicly increasing number? It makes for a 'easy' primary key. Also computers do not think in "Somelastname, SomeFirstname". They are basicaly super calculators. They LOVE integers.

      Lets do a 'C' example

      int x = 1;
      int y = 1;
      if (x == y) {//do some work}

      OR we could do this
      char *pX = "SomeString";
      char *pY = "SomeString";
      if (strcmp(pX,pY)) {// do some wo
  • by SlashDread ( 38969 ) on Monday September 06, 2004 @02:47PM (#10170255)
    Nothing to see here, move along..

    "/Dread"
  • Much has been made about the Chomsky quote at the top of the page. It *is* rather ironic that Chomsky is often way off base when it comes to political issues due to an a priori assumption that American capitalism is, necessarily, detrimental and oppressive.

    However, he is right in that quote, in that sometimes it's convenient to dismiss other people when you don't like what they have to say, and this is an impediment to objectivity.

    However, there's another side to this: sometimes someone will come around,
  • Fabian Pascal was a flaming asshole on every database-related forum on CompuServe 15 years ago. He was always posting about how he was right and everyone else was wrong, and about how his opponents were just stupid. Nice to see that in this ever-changing world there is a rock of stability.
  • SQL is terrible... (Score:1, Insightful)

    by morgdx ( 688154 )

    SQL is the worst language for accessing relational data, apart from all others that have been tried before.

    (Sorry Winston)

  • by Anonymous Coward on Monday September 06, 2004 @03:23PM (#10170473)
    Pascal makes a number of interesting points, although he does himself a disservice by wasting energy engaging some of the people here who probably were more interested in pushing his buttons than having a productive discussion. He does illuminate an ever-growing trend where acerbic, personalized, condemning rhetoric is perceived as an alternative to actual substance.

    This really bothers me. Everyone's welcome to criticize, but NOT everyone's opinion is equal (IMO). Take a person like Robert X. Cringely, who every other month has a goofy idea about how to get rid of spam, when his main experience with it is as your typical e-mail user and not a network administrator. His opinion pales in comparison to that of someone who is down in the trenches and has more experience and depth of knowledge. Unfortunately, Cringely and his bone-headed schemes get more attention than other, much-more-credible and much-more-realistic ideas proposed by those who have demonstrated that they are part of the necleus of the issue, as opposed to some journalist who's job is merely to regurgitate press releases and manufacture titillating bylines.

    We have a new breed of "experts" which aren't really experts in any field other than caustic communication.

    Mr. Pascal has a long and distinguished career and has been a visible pioneer in this industry. Perhaps his critics have equally illustrious careers involving the development of adult porn password databases, Starbucks employee management, kissing TA ass and other equally relevant disciplines that, when coupled with some clever put-downs compensate for a grand-canyon-sized disparity in real-world wisdom.

    Everyone's opinion is worth mentioning, but if you're going to dis someone like Pascal, you better open your fly and whip your own dick out and prove it's bigger.
  • From the article:

    The US system cannot use coercion (well, not at the Soviet level, at any rate, but the way things are going, give it time), so it must rely solely on propaganda, which must be believed. This means it's got to be very subtle and psychologically simple and attractive, rather than blatant and absurd, to be at once unobtrusive and effective. It's no coincidence that the mother of marketing and advertising originates here. If you step out of line, the government does not need to come after you

    • Yes, it is exactly that side of Pascal's persona (the Chomskyite side) that makes it so hard to see the value of his real accomplishments. Those he can't convince are automatically members of the mindless free-market apparatchik, and those he can convince are the brave but pitiable few who will be ground up and spit out by the soulless machine of modern commerce. Either way, you lose, it seems; and I think Pascal somehow wants it to be that way.

      Note that if you are one of the people out there who actually
  • by Anonymous Coward
    Be easy on the guy, he's got a lengthy track record of going hyper as a result of public BBS discussions.

    Long before there was a Slashdot or a public recognition of the internet, there was Compuserve and its discussion forums. One such forum, CONSULT, for computer consultants, would regularly see Fabian go into apoplectic seizures and jihaads of righting conceptual database wrongs. You'd log in to forum view and see threads that had 127 messages since that morning, for example; those were the ones where Fa
  • The argument of "Relational or Not" has the same religious overtones that the "Perl vs. Python" or "Emacs vs. VI" or "Linux vs. Windows" or "Democrat or Republican" arguments take. At the end of the day it is a subjective opinion and a personal choice made for personal reasons. One would hope that people would the better tool for the job.

    There is also the little issue -- that many have pointed out -- of needing to get work done. IF (and that is a big if) we all were to accept the premise that a truly rela

  • by Qbertino ( 265505 ) <moiraNO@SPAMmodparlor.com> on Monday September 06, 2004 @04:22PM (#10170860)
    ... he does actually have a point with his Introduction to REL [sourceforge.net]. I wrote a comment [slashdot.org] in the last article which puts SQL and DB design into perspective. It actually emphasises what he's trying to do with REL. There's no doubt: SQL does suck, whether it's sufficent to describe relations or not. And while you definitely shouldn't use a DB PL to design a DB (see other comment), we actually could use a successor to SQL.
    • The problem is if you stay on a relational level, you run into the main problem, that all your operations are basically done on mathematical sets.

      Now lets have a look at SQL, very clumsy, but it more or less is nothing else than a mapping of the mathematical set operations into something more verbose.

      Unless you define a new set of set operations (great sentence hey) or unless you move away from a strict mathematical set approach (like many did before) you always will end up with something similar to S
  • In the use of a sock puppet persona on Compuserve about 10+ years ago. He also got thrown off forum after forum. That's the price of being whatever he is.
  • He does have a point about people using xml for human readable formats sucking. I'm getting sick of having to edit ugly xml format config files. My though is if you are going to use xml to store startup/config data, give me an easier way to update my config. For example;

    ./updater -u name=value

    or better yet include a gui that can properly represent complex nested data structures. otherwise, what is wrong with the good old

    #standard txt config
    name=value

    XML configs do not help the end user to us

  • No, but it is a reasonable approximation in the real world. It seems like Fabian is complaining a lot about the difference between the pure relational model and the "impure" implementations. There is no such thing as perfect circle in the real world so what use is it to calculate the area or diameter using the full infinite expansion of pi? I don't need to understand why pi*r^2 calculates the area of a circle (in the sense of a rigorous mathematical proof) to actually do the calculation or make effective
  • According to the article it has been posted since July 23rd. It's now Sept 6...it's taken a month to recognize that this article was up?

1 + 1 = 3, for large values of 1.

Working...