Database heresies (The "right" and "wrong" way to do ORM)
1–10 of 18 posts
Re: Database heresies (The "right" and "wrong" way to do ORM)
#2FTA:
It turned out that relational databases were in the right place at the right time, and the “good enough” implementations and uses took over the world.
Yeah, that's what I've thought for a long time too. It's nice to see that in writing.
But I guess the rest of the essay leaves me a little cold. If the relational model is fundamentally flawed (rather: fundamentally mismatched to the overwhelmingly popular application design paradigm) then isn't the solution just to chuck the SQL database in the trash and start over?
So what has us tied to SQL and afraid of using the filesystem for storage directly? What are the other things we get from a database that we want? As far as I can see, the real need is for atomic transactions and consistent backups (or replication, which is the flip side of those features). No one cares about the "relational" stuff at all, really, as proven by all the awful ORMs out there.
And yet, if that were true, we'd all be happily using Berkeley DB. So what else am I missing? Some part of me thinks that there's a great startup idea in this space, but I don't quite see it yet. Tools like Google's App Engine seem to be attacking part of the problem by at least tweaking around with the SQL assumptions, but they're still fundamentally relational at their core (and they're still services, and my gut tells me that most of the world will never trust their data to someone else's service, no matter how well-justified it might seem).
Re: Database heresies (The "right" and "wrong" way to do ORM)
#3FTA: It turned out that relational databases were in the right place at the right time, and the “good enough” implementations and uses took over the world. Yeah, that's what I've thought for a long time too. It's nice to see that in writing. But I guess the rest of the essay leaves me a little cold. If the relational model is fundamentally flawed (rather: fundamentally mismatched to the overwhelmingly popular applica…
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)
#4FTA: It turned out that relational databases were in the right place at the right time, and the “good enough” implementations and uses took over the world. Yeah, that's what I've thought for a long time too. It's nice to see that in writing. But I guess the rest of the essay leaves me a little cold. If the relational model is fundamentally flawed (rather: fundamentally mismatched to the overwhelmingly popular applica…
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.
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)
#5Earlier quoted context omitted.
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.
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.
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)
#6Earlier quoted context omitted.
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.
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/
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)
#7Sigh. There is so much misinformation being spread by today's software engineers without proper CS backgrounds. As anybody who's read Date and friends knows, relational databases are fundamentally more expressive (and therefore better) than network databases (which is the model used by object databases), being grounded in set theory and predicate calculus.
Your bad taste for relational databases is more likely a result of using a crappy ORM pattern (such as Active Record). Go try a proper implementation of Data Mapper (I can't recommend SQLAlchemy highly enough), then come back and tell me how you feel.
Re: Database heresies (The "right" and "wrong" way to do ORM)
#8Sigh. There is so much misinformation being spread by today's software engineers without proper CS backgrounds. As anybody who's read Date and friends knows, relational databases are fundamentally more expressive (and therefore better) than network databases (which is the model used by object databases), being grounded in set theory and predicate calculus. Your bad taste for relational databases is more likely a resu…
Yes. And vans are more commodious (and therefore better) than cars.
Re: Database heresies (The "right" and "wrong" way to do ORM)
#9Sigh. There is so much misinformation being spread by today's software engineers without proper CS backgrounds. As anybody who's read Date and friends knows, relational databases are fundamentally more expressive (and therefore better) than network databases (which is the model used by object databases), being grounded in set theory and predicate calculus. Your bad taste for relational databases is more likely a resu…
Yes. And vans are more commodious (and therefore better) than cars.
Would you argue that the ability to form ad hoc queries for answering questions not originally imagined when writing an application fails to make the relational model superior to something without that property?
(I see you develop with Rails though, so probably yes.)
Re: Database heresies (The "right" and "wrong" way to do ORM)
#10Sigh. There is so much misinformation being spread by today's software engineers without proper CS backgrounds. As anybody who's read Date and friends knows, relational databases are fundamentally more expressive (and therefore better) than network databases (which is the model used by object databases), being grounded in set theory and predicate calculus. Your bad taste for relational databases is more likely a resu…
That sounds dangerously like pedantry to me. The point is not that the mathematical expressiveness of the network model is as powerful or more powerful than what you can do with relational stuff. The point is that the network model maps nearly 1:1 with the actual programming model used to implement the application logic.
All that relational goodness does you no good if you want to architect your application using an OO data model in a web application server. Maybe you're trying to argue that that's the wrong way to do web applications? But if you accept that people want to use Rails/Django/etc... then you have to also admit the argument that RDBMS's are the wrong tool for the job. This is true for the same reason that a Dremel is the wrong tool for framing a house, despite the greater expressive power of the Dremel's cutting tools.