Comments on: 6 Reasons Why Relational Database Will Be Superseded

By: Rackspace Cloud Computing & Hosting | NoSQL Ecosystem

Rackspace Cloud Computing & Hosting | NoSQL Ecosystem — Mon, 09 Nov 2009 05:38:07 +0000

[...] workloads. There are three specific problem areas: scaling out to data sets like Digg’s (3 TB for green badges) or Facebook’s (50 TB for inbox search) or eBay’s (2 PB overall), per-server [...]

By: rgfuller

rgfuller — Tue, 31 Mar 2009 02:41:53 +0000

Ok, so what will replace RDBMSes? What other technology has the ability or the potential to process transactions more quickly and answer queries with as much speed and flexibility (Ok – OLAP systems win here, but they are almost always used in conjunction with relational data warehouses).

It’s tiresome to hear complaints against RDBMSes without hearing any better ideas.

By: How the relational databases future will look like. | SimonOnSoftware

How the relational databases future will look like. | SimonOnSoftware — Fri, 09 Jan 2009 08:37:48 +0000

[...] http://havemacwillblog.com/2008/11/10/6-reasons-why-relational-database-will-be-superseded/ [...]

By: Chronicles of a Wandering Mind » Bookmarks for November 6th through November 12th

Wed, 12 Nov 2008 08:33:17 +0000

[...] 6 Reasons Why Relational Database Will Be Superseded | HaveMacWillBlog (aka Robin Bloor’s Blog… – The fundamental activities of Create, Read, Update and Delete are fundamentally wrong-headed. Updates to data should never be allowed, because they destroy information and Deletes should never be allowed for the same reason. When data changes the database should just add another record and note (by any mechanism that works) the previous value for that record. If the database gets too large then data should be archived from it. The right set of activities is thus CRA, Create, Read, Archive. All databases I’m aware of implement a CRUD model. [...]

By: DG

DG — Tue, 11 Nov 2008 12:49:05 +0000

I’ll try again:

However if you want to know the time frame for parallel and in-memory (or a combination of the two) to get traction, then that will happen in the next 6 years. It’s happening now in niche areas.

So now you’re backing off. Instead of saying the RDBMS will be replaced in the foreseeable future, you’re only saying that an alternative will “get traction” within 6 years. So what? A lot of technologies will “get traction” within the next 6 years.

By: DG

DG — Tue, 11 Nov 2008 12:48:12 +0000

Oops, it looks like I forgot to end my blockquote tag.

By: DG

DG — Tue, 11 Nov 2008 12:46:58 +0000

However if you want to know the time frame for parallel and in-memory (or a combination of the two) to get traction, then that will happen in the next 6 years. It’s happening now in niche areas.

So now you’re backing off. Instead of saying the RDBMS will be replaced in the foreseeable future, you’re only saying that an alternative will “get traction” within 6 years. So what? A lot of technologies will “get traction” within the next 6 years.

By: Mark

Mark — Tue, 11 Nov 2008 09:13:33 +0000

Very nice artice! Thanks for sharing!

By: kovica

kovica — Tue, 11 Nov 2008 06:08:49 +0000

I think relational databases are like COBOL. they will never go away.

By: Bloor Robin

Bloor Robin — Tue, 11 Nov 2008 05:14:49 +0000

This is no easy question to answer because old databases tend to live for a long time and what you are really asking (I think) is “when will new products become mainstream/dominant”. Unfortunately that depends on the market rather than the technology equation and I don’t know of any way to predict market behavior accurately However if you want to know the time frame for parallel and in-memory (or a combination of the two) to get traction, then that will happen in the next 6 years. It’s happening now in niche areas.
I can pretty much guarantee that it will happen because of the technical direction of chips (to multicore) and the decline in memory costs. The real trick would be to be able to say how it will happen – in terms of which products will get traction – but it’s too early to say for that.