3 ms·
Many people coming from dynamic languages rely too heavily on ORMs. It's not very hard to write some SQL that will do what you want it to do, and it'll almost a
by NateDad 14y ago
Many people coming from dynamic languages rely too heavily on ORMs. It's not very hard to write some SQL that will do what you want it to do, and it'll almost always be faster than an ORM. There is a little more setup, but it's not really that hard unless you have a really huge data model. Also, many people are moving away from relational databases for web platforms anyway, and non-relational databases are a lot easier to write code against. Check out the mgo package for running against mongodb.
- grey-area 14y agoI don't think people use ORMS because relations are hard, but because they are boring, repetitive, and just complex enough to make them tricky but not interesting. So ORMS are used to take away some of that cognitive load when you just want to say that Story has_many :commenters, via: comments or something similar. It's simpler to express what you want, gets rid of boilerplate joins etc, and usually you can drop down to SQL if you need it to fine tune a query, so why not? Re relational versus non-relational, they're really suitable for different kinds of data, and it's disingenuous to suggest that one is the future and one is the past.
- tptacek 14y agoThis; the moment I realized I was never going to choose to do CRUD web stuff in Go was when I realized that this was the perspective Golang developers have on ORMs.
- mbreese 14y agoThat's funny... knowing that ORMs aren't everywhere actually makes me more likely to use Go. I still have Hibernate flashbacks.
- boundlessdreamz 14y agoHave you used rails ORM (activerecord) or sqlalchemy ? (I haven't used the latter much but people rave about it). Hibernate is an ORM taken to the extremes
- lobster_johnson 14y agoHibernate is not a good example of an ORM, frankly. (I myself have horrors of both Hibernate and TopLink, which was the top Java ORM way back when.) Ruby's ActiveRecord is a much better choice. It has an excellent balance between SQL and OO. It doesn't pretend that SQL doesn't exist; on the contrary, it encourgaes SQL use, and merely maps tables to objects, adds a bunch of useful features (data validation, change management, automatic joins, declarative migrations) and gets out of your way most of the time. For example: users = User.where("created_at > ?", Time.now - 1.year). order('name').limit(10) Results are lazily loaded and composable, so you can do: users = User.where("created_at > ?", Time.now - 1.year) if (page = params[:page]) users = users.offset((page - 1) * 10).limit(10) end Joining is easy: users = Users.joins(:accounts). where(accounts: {type: 'facebook')).first becomes something like: select users.* from users join accounts on accounts.id = users.account_id where accounts.type = 'facebook' limit 1
- ux-app 14y agoPersonally I don't like ORMs because they're black boxes. When some complex model relationship results in crappy generated SQL (which I've experienced a number of times) I had to sit down and write SQL. The problem being that after a couple of years of ORMing my SQL skills had atrophied. So now I've gone fully circle: from SQL to ORM and back to SQL.
- cageface 14y agoAt first when I started doing Android apps I was writing raw sql code. I very quickly remembered how tedious and repetitive this is and went running for the nearest ORM. Nothing feels better than ripping out huge chunks of boilerplate.