Time to rewrite DBMS, says Ingres founder

I don't necessarily agree with his claim that SQL or anything like SQL is unnecessary. While SQL is wordy and oftentimes clunky, it is language-neutral, works predictably across all systems accessing the same database, and doesn't tie the application developer to object-centric (not necessarily OO but leading there) design. It seems like Stonebraker is advocating Ruby here because of the hibernation features native to Rails, which is object-centric as it ties classes defined in the application to database tables. It's a sensible abstraction on top of the loose link between applications and DBs for some applications, but e.g. extract-transform-load applications would be hindered by this abstraction more than helped.

By contrast, I think one thing that DBMSs could make steps towards obviating is explicit optimizations. Instead, there should be support in the language for telling the DBMS what's important when you do your DDL, then let it figure out indexing, reclamation, replication, and batch scheduling. I see this as being a similar optimization to GC -- the runtime performance will initially be in doubt, but it will ultimately enable the creation of complex systems with far less human effort.

What strikes me about sql is that new programmers think even the smallest shrinkwrapped desktop app that persists data has to ship with a db engine with a sql interface. The ultimate result is all this modelling that's done to generate SQL for your interfaces using some fancy toolkit. The problem with this is that it creates an appearance of separation by generating a bunch of business objects for you. But it still encourages designing interfaces with data access in mind = monolithic development.

SQL is especially good for those times when you do not have all the answers for the questions that may be asked of your data. But if you already know all the ways your data will be queried, what's the point?

I just saw a presentation on Franz's Allegro-graph - a system that stores triples up to the billions with very advanced query abilities: We are seriously considering using this: (they have a free java version that supports up to 50,000,000 triples) http://agraph.franz.com/allegrograph/

Phil Manchester is the same guy over at regdeveloper who wrote this badly paraphrased executive summary of blog posts: http://www.regdeveloper.co.uk/2008/01/24/stonebraker_dewitt_... .

Curt Monash's take on it :-

http://www.dbms2.com/2008/02/18/mike-stonebraker-calls-for-t...

many, if not most, high-end OLTP systems didn't (and don't) use relational technology anyway. Programmers do what's necessary to get the job done. IOW this is preaching to the choir.

Uh...somebody already did this, and called it MySQL. It's been fairly successful, though universally reviled by database experts who know what they're doing...

Doesn't Lisp already do this?

I'd be hard pressed to envision a DBMS for business WITHOUT ACID. Transaction processing has to be "somewhere", and the DBMS has always seemed like the most appropriate place.

I remember the days when we had to roll our own record locking, transactions, and stored procedures, and don't relish going back.

SQL, OTOH, can hit the road and I'd never miss it. No problem putting it's job into my language du jour.