News for hackers. Stuff that matters.
Re:Database heresies (The "right" and "wrong" way to do ORM) by stcredzero on Monday August 04, 2008 @05:26PM (#266796)
A big part of the reason for Relational DB's continued supremacy, is that it's become a part of the back-end language of business IT. Even though an OODB might be a better fit for an application, it's a handicap that your app is not on top of a relational database. SQL has become a kind of protocol for data exchange. Unfortunately, it makes for a very loose and sloppy protocol that completely spoils encapsulation.
Re:Database heresies (The "right" and "wrong" way to do ORM) by ajross on Monday August 04, 2008 @05:30PM (#266801)
Sure. I'm not expecting something new to displace SQL at a Fortune 500 IT shop. But the question is why are otherwise-groundbreaking technologies like Rails still wedded to the ORM stuff, when clearly there isn't any conservatism at work there. Anyone willing to bet the company on some weird language from Japan isn't going to blink about changing their datastore.
Re:Database heresies (The "right" and "wrong" way to do ORM) by jimgreer on Monday August 04, 2008 @05:41PM (#266812)
Actually one of the most interesting things at RailsConf was MagLev, which applies the GemStone object persistence engine to Ruby. Apparently there are some pretty big Smalltalk apps out there using GemStone. http://chadfowler.com/2008/6/5/maglev and http://ruby.gemstone.com/
Re:Database heresies (The "right" and "wrong" way to do ORM) by stcredzero on Monday August 04, 2008 @06:15PM (#266855)
One of the interesting technologies that Gemstone has had in its portfolio for years is the ability to make its data available in relational/SQL DB form. You can have your app running on top of an OODB, but still interface with your Fortune 500 comrades who want to do SQL queries for Crystal Reports.
Re:Database heresies (The "right" and "wrong" way to do ORM) by huherto on Tuesday August 05, 2008 @10:33AM (#267475)
I had the opportunity to work with Smalltalk/Gemstone in 1994. At that time we thought OODBMS was the next big thing. Programming was easier. However, soon it was clear to me that OODBMS was not the way to go. For example versioning is quite simple in an RDBMS compared to an OODBMS.