Make just as much sense as the headline.

The relational model is just that -- an abstract model which defines how data can be represented.

A relational database is a piece of software that cofroms to the rules of hte relational model. There are no constaints on hte implmentation, and, indeed modern relational databases are usually multi-htreaded, multi-process and in many cases multi machine beasts. Internally map-reduce is often used to optimise and parallelize query processing.

SQl itself is ver far from dead and is constanly evolving (new verbs like COALESS are appearing all the time) my main gripe with SQL is that its the most difficult grammer to write a parser for -- the number of places where a select statement can appear inside a select statement is staggering.

This is not to say that RDMS is the only valid approach, new technoligies like googles "Big Table" are impressive, and, there are still many thousand "old technoligy" databases like IMS, IDMS out there. I wonder if anyone is still using TOTAL?

These "Relational Is Dead" stories are getting as tiresome as "The Mainframe is Dead".

Other than to say a couple of things.

1. Linq can be used to query tables. The same expression can also access objects which if they're accessed via Ado.Net for entities, or the misnamed nHibernate (it should be eponymously called zzzzzzhibernate,) means an array of VLDBs servers can provide an application object relational access to a cloud of objects.

2. SQL Server isn't, and never has been, a relational database. I get fed up to the back teeth defending arguments from people who maintain my solutions shouldn't be allowed, because I perform set based DMOs in some non random order. SQL Server is a software product which amoung other things, implements the relational paradigm.

3. That said, the relational model isn't dead. It's merely a subset of the world of data.

The solution to BI queries are shells of staging data, derived from the don't repeat yourself datasets.

One of them at least, is the way in which people want to retain junk.

You must know people who live like this - collecting 'useful' bits of wood, stones, old magazines, bottle tops, containers, newspapers... seemingly unable to get rid of old crap they don't, won't and could never really need.

Data collectors have the same issue. Reams upon Reams of crap data - will never, could never be processed for any useful purpose, but kept on tier 1 storage anyway. Slowing down the system, magnifying DR issues, complicating every angle.

Ditch the rubbish. Store efficiently.

How long have so called experts been forcasting the death of Unix? Doesn't seem to be hurting Linux at the moment. How long have been promised "new paradigms in GUI design", well baring Apple moving the menu bar to the top of the screen, we still seem to be stuck with windows with stuff we want, in 'em, whether it be Windows, KDE, Gnome, OSX, etc. We've added flashy twirly stuff, Aero and Compiz, but they're still square bits of screen real estate with the stuff we need printed in them.

The thought of Steve Ballmer unveiling anything "with a strong bi flavor" is an image so repellent that I felt compelled to share it with you all.

Once again even the "gurus" fail to recognize the nuances of the argument, and once again they propose solutions to the wrong problem. The traditional view is that RDBMs embrace and embody the Relational Model, and since they may not be able to scale to modern needs, this is therefore an indictment on the Relation Model. At the root of the problem is that this argument is faulty because its assumptions are wrong.

The Relational Model is a mathematical model, designed to impart coherence, structure, and integrity to the amorphous data it contains. At its heart is a strong separation between the logical model (how users interact with it and organize the data logically) and its physical layer (how its actually stored and retrieved in practice). The Model defines everything about the former, and says nothing (except perhaps makes some accidental suggestions) on the latter.

It has been understood for decades that modern DBMS systems tend to commingle both layers in an effort to simplify design and improve performance. This is not dictated by the Relational Model, and in fact deviates from it. Also, SQL is decidedly not relational, but a declarative language with many faults and limitations. The fact that modern DBMS systems anbd SQL are not able to cope with the necessities of the modern business world says nothing about the Relational Model itself; so looking to "solve" or "fix" or even replace the it is not necessarily warranted.

-dZ.

How long before Aaron "Database" Kempf flames this story?

I remember this article from 10 years ago.

I see you've updated some of the players. And the term "object oriented" was so very sexy in those days--I'm sorry to see it go.

And speaking of sexy: "Bi" and "huge?" Far out!

You definitely went out of your way to avoid mentioning Teradata.

Of course TeraData was not mentioned. They have a Data Warehouse solution that works. Oracle introduced an "appliance" so they can pretend that they do Data WareHouse and wanted the world to think that this was a new problem only Oracle could solve.

Amen DZ-Jay. The Relational Model is just that: a model. But it's still important. If you don't grok why 3NF is, under a not-unreasonable set of circumstances, a good structure for your DB to have then you probably shouldn't be let loose on the world of actual data. Yes, you can deviate from the model, and in the corporeal world, far from Messrs. Boyce and Codd, you probably will. But without an understanding of why the relational model was developed, diversions from it are an appeal to magic. At the very least, no new paradigm that does not incorporate the 'C' in ACID is broken.

I will not tinker till its broken. I will not tinker till its broken. I will not tinker till its broken. I will not tinker till its broken. I will not tinker till its broken. I will not tinker till its broken.

LALALALALALALAA... I am decidedly NOT listening.

At the risk of being boring, MapReduce is a way of processing data, not a way of storing it.

Paris, coz she lost her relational database once.