back to article Codd almighty! How IBM cracked System R

Few teams have maintained such a fierce community spirit as the IBM pioneers of System R. In Silicon Valley in the early 1970s, this pioneering team proved that a relational database could actually work. It's a fascinating story, best known today because IBM failed to capitalise on its research. But it's also a timeless one, …

COMMENTS

This topic is closed for new posts.
  1. Nifty Silver badge

    The hair styles of the day indicate that job security was not an issue then.

    1. Anonymous Coward
      Anonymous Coward

      Nope, you still get "hair styles" amongst the suits and business casuals in the canteen at IBM labs...

  2. Peter Gathercole Silver badge

    Ingres and 2BSD

    Ingres was available for free (or at media and postage costs) to Universities and Colleges who had a UNIX source code license. I believe that it was on any 2 BSD add-on tape (it was certainly on the 2.6 BSD tape I had in 1982).

    The University I was at (Durham, UK) was using Ingres to teach relational database in 1978, and I came across it in my second year in 1979.

    I must admit that I could not stand it as a subject, because the lecturer was using set theory to try to teach relational algebra, and my maths was beginning to look a little shaky by that time, but when I ended up actually doing real work, I found QUEL quite usable. It took quite an effort to switch to SQL when I had to work on Digital's Rdb, Oracle and DB/2.

    I don't count databse as a current skill now, but I still regard the experience I gained as invaluable.

  3. Kubla Cant

    The fourth R

    Almost all the systems I've worked on in the past 20 years have used relational databases as their back-end storage. One curious thing I've noticed is the extent to which otherwise competent, even brilliant, developers fall apart when they start to work on a database.

    It's the same thing over and over. A primary key is too much trouble - let's just have a unique index. Normalisation is for anal-retentive obsessives. Why use a surrogate key when we can index several attributes? Let's just pretend that the database is a kind of flat-file storage.

    This surprises me. I'm a self-taught developer with nothing more than O Level maths, but it seems obvious that getting the data design right is fairly easy and pays big dividends. My colleagues, on the other hand, who have been educated and trained to a high level in this stuff, mostly fail to get it.

    1. Anonymous Coward
      Anonymous Coward

      Re: The fourth R

      Yes. There's a simple answer to this OO-programming turns your brain to mush

      1. Kubla Cant

        Re: The fourth R

        OO-programming turns your brain to mush

        I'm an OO programmer myself, so I'm bound to disagree, either because you're wrong, or because my mushy brain is incapable of seeing that you're right. Mushy or not, it can identify the syntax errors in your post.

  4. Gene Cash Silver badge

    That building

    Looks a hell of a lot better than Apple's "spaceship"

    1. Tom 13

      Re: That building

      Reminds me of my elementary school actually.

  5. Anonymous Coward
    Anonymous Coward

    Good article

    But the best part are the pictures. :-)

  6. Rocksandwater

    Multics Relational Data Store was first on market

    Funny you mentioned Multics in the article, but did not mention that Honeywell was first to commercial market with a relational database: Multics Relational Data Store (MRDS) in 1976.

    In another strange twist, the Honeywell team built a hierarchical database as a layer on top of MRDS to meet market demands: MIDS.

    First mover advantage? Not.

  7. Andy Davies

    You had to be there..

    ..when you'd learnt to program with flat files and moved on to hierarchical the mental contortions needed to think in relational terms were horrendous. Relational was just not a programmers' way of thinking.

    The conversion was worth the effort but I suspect that the success of relational databases wasn't just down to SQL - "Locking and concurrency issues were tackled, too.... the hard problems were: recovery, transaction commit, concurrency control... " it was also the fact these issues had been handled for you, having tried to write recovery logic for a double-chained IBM database system at the beginning of the 70's I have a vague idea just how hard those problems were.

This topic is closed for new posts.

Other stories you might like