

Time to rewrite DBMS, says Ingres founder - pmattos
http://www.regdeveloper.co.uk/2008/02/18/stonebraker_dbms_outdated/

======
airhadoken
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.

------
jksmith
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?

~~~
systems
i would say tables are easier to use and conceptualize about, rather than
files, lines and such!

with tables you directly deal with your porgramatic objects you dont think of
storage, plus sqlite is very easy to use and very portable too!

------
gibsonf1
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/>

------
bayareaguy
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_...](http://www.regdeveloper.co.uk/2008/01/24/stonebraker_dewitt_mapreduce)
.

------
andyjenn
Curt Monash's take on it :-

[http://www.dbms2.com/2008/02/18/mike-stonebraker-calls-
for-t...](http://www.dbms2.com/2008/02/18/mike-stonebraker-calls-for-the-
complete-destruction-of-the-old-dbms-order/)

------
giardini
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.

------
nostrademons
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...

------
jmzachary
Doesn't Lisp already do this?

~~~
alexfarran
I want that on a t-shirt!

------
edw519
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.

