Comments on: Another round of discussion on in-memory OLTP data management http://www.dbms2.com/2008/09/25/another-round-of-discussion-on-in-memory-oltp-data-management/ Choices in data management and analysis Thu, 09 Feb 2012 21:52:17 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Chris Bird http://www.dbms2.com/2008/09/25/another-round-of-discussion-on-in-memory-oltp-data-management/#comment-119404 Chris Bird Fri, 01 May 2009 12:01:38 +0000 http://www.dbms2.com/?p=574#comment-119404 I have just been reading the various white papers sent to me by Vertica. C++ is feartured front and center. IMHO the language needs to be slightly higher level - you don't want to be in a place where a pinhole sized memory leak brings down the whole database. I can un understand why Ruby would be eliminated, there really aren't (yet?) any rocking fast VMs that I know about. It would be interesting to see the Model code of Rails's MVC etructure execute "down there" though. That leaves us with java. As long as they stay away from EJB, and do something lightweight, I suppose that will be OK. Since Oracle owns it (or will soon), every DBMS vendor that embeds java will at least look twice. Whatever the method, there has to be a whole lot better IDE, debug and development support than the version 1.0 kinds of stored procedures that we see today. I would expect: Realtime debuggers Unit test frameworks Refactoring capabilities Version management Team development capabilities all to be present before the thing can be considered ready for prime time. I have just been reading the various white papers sent to me by Vertica. C++ is feartured front and center.

IMHO the language needs to be slightly higher level – you don’t want to be in a place where a pinhole sized memory leak brings down the whole database.

I can un understand why Ruby would be eliminated, there really aren’t (yet?) any rocking fast VMs that I know about. It would be interesting to see the Model code of Rails’s MVC etructure execute “down there” though.

That leaves us with java. As long as they stay away from EJB, and do something lightweight, I suppose that will be OK. Since Oracle owns it (or will soon), every DBMS vendor that embeds java will at least look twice.

Whatever the method, there has to be a whole lot better IDE, debug and development support than the version 1.0 kinds of stored procedures that we see today.

I would expect:
Realtime debuggers
Unit test frameworks
Refactoring capabilities
Version management
Team development capabilities

all to be present before the thing can be considered ready for prime time.

]]> By: Curt Monash http://www.dbms2.com/2008/09/25/another-round-of-discussion-on-in-memory-oltp-data-management/#comment-119349 Curt Monash Fri, 01 May 2009 00:46:57 +0000 http://www.dbms2.com/?p=574#comment-119349 I'm not going to check my notes as to what the latest language plan is for the most advanced H-Store commercialization project for H-Store is, since it was under NDA otherwise. (But please contact me privately about same if you care.) All I recall is that the Ruby idea was dropped due to performance. I'd expect good language flexibility to be in early, whether or not it actually is there Day 1. I’m not going to check my notes as to what the latest language plan is for the most advanced H-Store commercialization project for H-Store is, since it was under NDA otherwise. (But please contact me privately about same if you care.) All I recall is that the Ruby idea was dropped due to performance.

I’d expect good language flexibility to be in early, whether or not it actually is there Day 1.

]]> By: Chris Bird http://www.dbms2.com/2008/09/25/another-round-of-discussion-on-in-memory-oltp-data-management/#comment-119312 Chris Bird Thu, 30 Apr 2009 22:30:47 +0000 http://www.dbms2.com/?p=574#comment-119312 The whole stored procedure in C++ thing scares the living daylights out of me. I have never been a huge stored procedure fan, but then to have to downgrade to C++ in a proprietary fashion - that just seems like a strange way to go. I understand the logic, but it would have to be an otherwise compelling solution for me to contemplate it. The whole stored procedure in C++ thing scares the living daylights out of me. I have never been a huge stored procedure fan, but then to have to downgrade to C++ in a proprietary fashion – that just seems like a strange way to go.

I understand the logic, but it would have to be an otherwise compelling solution for me to contemplate it.

]]>