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.

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?

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.