News: Relational databases are obsolete

I guess this article from ComputerWorld.com means that we can expect
FileMaker 10 to be a totally different application. ;o)


Relational database pioneer says technology is obsolete
-------------------------------------------------------
As a researcher at the University of California, Berkeley,
in the early 1970s, Michael Stonebraker co-created the
Ingres and Postgres technology that underlies many leading
relational databases today: Microsoft Corp.'s SQL Server,
Sybase Inc.'s Adaptive Server Enterprise, Ingres Corp.'s
eponymous product, IBM's Informix, and others.

But Stonebraker now argues that relational databases,
also known as RDBMSes, are "long in the tooth" and
"should be considered legacy technology."

In an entry Tuesday at a new blog, The Database Column,
Stonebraker also argued that today's relational databases
lag badly in performance behind a new wave of databases
that flip database tables 90 degrees.

Column-oriented databases -- such as the one built by
Stonebraker's latest start-up, Andover, Mass.-based
Vertica Systems Inc. -- store data vertically in table
columns rather than in successive rows.

... continues at http://tinyurl.com/2ecol5



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Re: News: Relational databases are obsolete

On Sep 7, 12:33 am, Helpful Harry
wrote:
> I guess this article from ComputerWorld.com means that we can expect
> FileMaker 10 to be a totally different application. ;o)
>
> Relational database pioneer says technology is obsolete

That article was badly written and misleading imho. Relational
databases aren't obsolete. OTOH the universal use of row-oriented
storage might be. (and even that isn't quite as universal as one might
think; most databases don't use row-oriented storage for (varchar)
variable length text fields, binary blob (containers) already. And the
techniques they use for that are similiar to what's going on with
column oriented storage. All he's done is taken that to the next
level; so that even traditional fixed width fields are stored with
their column-mates instead of their row mates.

But to the user, column storage vs row storage is an invisible
implementation detail. (on the same level that connecting to a real
database file vs a filemaker server is invisible).

Relational database theory, query systems, or user interfaces couldn't
care less whether the actual storage is row based or column based, and
indeed, Filemaker could be using column storage right now and we'd
never know. Its a detail handled by the database engine at a pretty
low level. (And in fact, given that filemaker allows variable length
text in nearly all its field types it wouldn't really surprise me if
its almost a column oriented system already.)

The main difference between row and column storage is simply in its
read / write characteristics. Apparently it turns out column storage
is more efficient for (most) read heavy data warehousing/mining
systems where only a few columns in the data set are looked at for a
given query, while row oriented is more efficient for (most) write
operations (as every column gets allocated during a write).

cheers
-Dave