Re: Is there a "third generation" DB yet?

jim caprioli wrote:
> All this functionality is available today although not in what we call
> the 'database'.

Is it? In earlier posts to this group the opinion that OO data schemas can be properly replaced by better database design without the need for having OO representation within the database.

I agree that people should use the right tool for the job. This is sometimes lost in the computer world (reference the "when all you have is a hammer" statements in earlier posts).

I worked on projects where in spite of having some brilliant database people involved we were unable to design a relational database that was unable to handle the kind of questions that needed to be asked. The result was a very spread out set of tables, some very clever SQL to attempt to limit the unavoidable 500MB+ return sets. The return data was then translated into the appropriate web/network/directed graph schema for the application to perform analysis on to isolate the the very small subset of data that the user was really looking for.

At each of those times more then a few people lamented "If only we could hand the DB a partial web/network/directed graph schema and ask for any data that looks like it. That would cut the returned subset to 100MB. Plus we could avoid the parse to from/to SQL stage."

I admit that the questions being asked where very hard to model in the first place (transient closure queries, object relationship distance queries, etc.). Each of the solutions always seemed to fall very short for what we expected to be able to do given the "advanced state" of RDBMSs and 4GLs.

I am not suggesting we should put the kitchen sink into an DBS or a DBMS. I am a BIG fan of the KISS principle. Yet the questions remain unanswered. What is missing in today's DBS solutions? What data schemas are causing problems? Can they truly be corrected with better DB engineering or do we need to add some fundamental missing bits to the underlaying DBS engine to allow the DBMS to better handle the data and applications we are now trying to produce.

> Grid Computing sounds 'cool'. I apologize, I am going OFF-TOPIC here. I
> replied because I just don't see any innovation in the list of features.

Yes Grid computing is very cool. But, what does it ad to a DBS? There is little shared disk space, there can be multiple read copies but one master write server (bottle neck). The Grid solution is a lot like throwing hardware at the problem... "the DB is slowing down -- OK heres another $5K add more memory and faster disk." That can only be taken so far.

> My point: It doesn't matter where functionality is implemented.

It may, then again it may not. I cringe every time I walk by the $5 million database server with its 16 CPUs, 1GB RAM per CPU attached to the fiber SAN and 10TB RAID cabinets. Why? Simply because all of that expensive hardware is being used for one purpose -- as a big hard disk. The DB server takes SQL and dumps back the data. I want to be able to hand off to the DBS a query and maybe an analysis and get back either a significantly reduced chunk of data for closer examination or preferably the completed analysis ready for display. That would be using that lovely hardware much more efficiently.

> Sounds like science fiction but that is where most innovation starts.

Imagination and necessity is all it takes for the next innovation.

Cheers,
Scottie Received on Fri Apr 16 2004 - 00:47:56 CEST