Re: Table driven, massively parallel RDBMS in the future

From: BobTheDataBaseBoy <"xxx>
Date: Tue, 13 Feb 2007 22:57:28 -0500
Message-ID: <7L6dnZ-QMoyYFU_YnZ2dnUVZ_hSdnZ2d@rcn.net>

mountain man wrote:
> "-CELKO-" <jcelko212_at_earthlink.net> wrote:
>

>> My model of the future of RDBMS is that we will have multi-core chips
>> (INTEL is promising 80 in the near future) combined with secondary
>> storage that has the seek times of current semi-conductor primary
>> storage.  This will make massively parallel RDBMS the norm.

>
> Will there still be Application Servers in this future environment?
> Will software code still exist in abundance external to the RDBMS,
> or will the increased use of stored procedure based solutions imply
> both all the data and the majority of the code be housed within the
> RDBMS?
>
>
>
>

One can only hope so. A handful of weeks ago, spurred on by some threads on various java sites I follow, I posited the question whether the brave new world of multi-core and thread dependent/capable languages (not necessarily java; not all think its threading is really spiffy) would spell the return to application (i.e. client) driven data control. For those not old enough to have been there => COBOL/VSAM paradigm.

The general tenor of the response was, "there, there deary don't worry".

Since then, those same and similar sites have generated lots of angst that may be this is all too much for your average application coder, regardless of language.

My conclusion from the beginning was that the database engine development community, owing to its connection to Big Iron multiprocessors, has been dealing with the issue for a longer time. And as has been mentioned many times, never ever trust concurrency and integrity to the client.

There has been for at least a couple of years, a code generation underground. Andromeda and Little Steps get mentioned here. There are others connected to various languages, mostly java.

If someone could only gin up a study showing performance is an order of magnitude better doing C&I only in the database, relegating the client to display and input (kind of like, well, X-windows).......... And wait for those COBOL programmers to die (and prohibiting survivors from procreating), of course. Received on Tue Feb 13 2007 - 21:57:28 CST