Time to rewrite DBMS, says Ingres founder(regdeveloper.co.uk)
regdeveloper.co.uk
Time to rewrite DBMS, says Ingres founder
http://www.regdeveloper.co.uk/2008/02/18/stonebraker_dbms_outdated/
9 comments
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?
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 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!
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!
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...
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...
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.
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.
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.