4 ms·

Surprised by the pro-ORM comments so far. My hate for ORMs grew proportionally with my usage of NoSQL. It's such a pleasant experience when your domain model f

by latch 14y ago

Surprised by the pro-ORM comments so far. My hate for ORMs grew proportionally with my usage of NoSQL. It's such a pleasant experience when your domain model fits the data model. Graphs are a good example, but Redis is a better one. When your intention fits a Redis data structure, it's just programming bliss - a few lines of explicit and simple code. The only way I can use a relational database now is with Sequel.

polyfractal 14y ago
I'm confused by your statement. When your data fits the tool that was designed to work with that data...everything is great? Isn't that the point of using the right tool for the right job?
- latch 14y ago
  What's confusing? For years...decades...developers have been taking a one-size-fits-all approach to data storage - relational databases. Now that we are starting to make use of more specialized tools, we're starting to go back and question (or hate) our past approach.
andrewcooke 14y ago
it depends so much on the context. i work with a wide range of different technologies. when i'm doing "enterprise" stuff, i tend to avoid the heavy orm like hibernate and go for things that give me more control (spring's helper classes, say). so you can say that i am "avoiding orm". but then recently i've been writing c code that needs to use a small database and boy, it's tedious working with sql directly. so i'm actually writing an "orm for c". it's all about balance... [the orm for c thing is basically two layers - a simple library that helps make sql queries a little easier to mangle and then a python library that, given some structs and a database, will auto-generate some basic boilerplate via the library. nothing fancy, but it will save a pile of tedious work.]
mechanical_fish 14y ago
From the article: I think NoSQL is technology to be taken very seriously… But even so it only works when the fit between the application model and the NoSQL data model is good. Not all problems are technically suitable for a NoSQL database. And of course there are many situations where you're stuck with a relational model anyway. Maybe it's a corporate standard that you can't jump over, maybe you can't persuade your colleagues to accept the risks of an immature technology. In this case you can't avoid the mapping problem.

by latch 14y ago

polyfractal 14y ago

I'm confused by your statement. When your data fits the tool that was designed to work with that data...everything is great? Isn't that the point of using the right tool for the right job?

latch 14y ago
What's confusing? For years...decades...developers have been taking a one-size-fits-all approach to data storage - relational databases. Now that we are starting to make use of more specialized tools, we're starting to go back and question (or hate) our past approach.

andrewcooke 14y ago

it depends so much on the context. i work with a wide range of different technologies. when i'm doing "enterprise" stuff, i tend to avoid the heavy orm like hibernate and go for things that give me more control (spring's helper classes, say). so you can say that i am "avoiding orm". but then recently i've been writing c code that needs to use a small database and boy, it's tedious working with sql directly. so i'm actually writing an "orm for c". it's all about balance... [the orm for c thing is basically two layers - a simple library that helps make sql queries a little easier to mangle and then a python library that, given some structs and a database, will auto-generate some basic boilerplate via the library. nothing fancy, but it will save a pile of tedious work.]

mechanical_fish 14y ago

From the article: I think NoSQL is technology to be taken very seriously… But even so it only works when the fit between the application model and the NoSQL data model is good. Not all problems are technically suitable for a NoSQL database. And of course there are many situations where you're stuck with a relational model anyway. Maybe it's a corporate standard that you can't jump over, maybe you can't persuade your colleagues to accept the risks of an immature technology. In this case you can't avoid the mapping problem.