4 ms·

> This is basically a big, complicated, and slow piece of software that tries to make a SQL database into something else. Just to nitpick a little, but I think

> This is basically a big, complicated, and slow piece of software that tries to make a SQL database into something else. Just to nitpick a little, but I think it's a worthwhile distinction, ORMs don't try to make a SQL database something else... either literally or philosophically. To use them in any more than a trivial way you still to understand RDBMSs. They just make the queries less verbose and the output more convenient to work with.

189723954 8y ago
You are just defining the limits of "something else" and then saying it doesn't do that. If your data looks completely differently to how the database outputs it, I don't think you can say it is just a trivial difference. Both the structure of a query and its output use different concepts to sql. Using linq, a query will look like: db.Products.Include(p => p.manufacturers).Include(p => p.parts).where(p => p.name == 'bike').ToList(); in sql, it is SELECT * from products, manufacturers, parts, JOIN ...... ON ......... The linq query syntax makes it seem like you are just plucking a Product out of a database that has manfufacturer and a list of parts as part of its object. It is an object, not a row and table based structure. Then the output itself is also an object, in a completely different structure to what the database gave to you. People can use an ORM and not really know how SQL works if they never bother to learn. It is presenting them with an object-based database. In a NoSQL database like Mongo, you either have to literally store the Product with its parts and manufacturer, or you take them separately from the database and put them back together in code. This requires no abstraction. It is exactly what is happening.
- dang 8y ago
  Could you please stop creating new accounts for every few comments you post? We ban accounts that do this, and it's in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. It's particularly abusive that you used multiple accounts in this same thread. HN is a community. Obviously you don't have to use your real name, but if users don't have some consistent identity for others to relate to, we may as well have no usernames and no community at all. That would be quite a different kind of forum. Anonymity is fine, and throwaways for a specific purpose are ok—just not routinely. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0&query=by:dang%20community%20identity https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...
threeseed 8y ago
> ORMs don't try to make a SQL database something else This is simply not true. Many ORMs are designed to abstract away SQL and RDBMS concepts entirely. They deal in objects and object graphs and output SQL which can be quite disjointed from the object model e.g. many-many relationships.
- vinceguidry 8y ago
  I'm becoming increasingly convinced that there is only one good ORM and the rest are fit only for CRUD operations. ActiveRecord. The abstraction it provides is amazingly flexible. You can be as close to the SQL as you want to be. With other ORMs, any time I need something not CRUD, I wind up hand-generating SQL. With ActiveRecord, I never need to. Looking at generated SQL, I do all the time with AR, happily it makes that very easy for me. Including my own SQL snippets in scopes? Easy. Hand-generating joins? Almost never.
- richmarr 8y ago
  > This is simply not true. Providing a wrapper around a thing is not the same as wanting to turn a thing into something else. I would argue that ORMs offer cosmetic change. Convenience, not substantive change. > Many ORMs are designed to abstract away SQL and RDBMS concepts entirely. Which ones? Look at their docs and you'll see where conditions, joins, columns, ordering, aggregations, etc. ActiveRecord is probably the most abstract I've seen and the docs still refer endlessly to tables, foriegn keys, etc and show SQL equivalents http://guides.rubyonrails.org/active_record_basics.html#creating-active-record-models http://guides.rubyonrails.org/active_record_basics.html#crea... Here's Hibernate: http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single/Hibernate_User_Guide.html#fetching http://docs.jboss.org/hibernate/orm/5.3/userguide/html_singl... Here's Sequelize: http://sequelize.readthedocs.io/en/v3/docs/querying/#basics http://sequelize.readthedocs.io/en/v3/docs/querying/#basics Here's SQLAlchemy: https://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html https://docs.sqlalchemy.org/en/latest/orm/loading_relationsh... I would say that ORMs as a class rely heavily on SQL and RDBMS concepts... particularly for anything beyond simple CRUD

189723954 8y ago

You are just defining the limits of "something else" and then saying it doesn't do that. If your data looks completely differently to how the database outputs it, I don't think you can say it is just a trivial difference. Both the structure of a query and its output use different concepts to sql. Using linq, a query will look like: db.Products.Include(p => p.manufacturers).Include(p => p.parts).where(p => p.name == 'bike').ToList(); in sql, it is SELECT * from products, manufacturers, parts, JOIN ...... ON ......... The linq query syntax makes it seem like you are just plucking a Product out of a database that has manfufacturer and a list of parts as part of its object. It is an object, not a row and table based structure. Then the output itself is also an object, in a completely different structure to what the database gave to you. People can use an ORM and not really know how SQL works if they never bother to learn. It is presenting them with an object-based database. In a NoSQL database like Mongo, you either have to literally store the Product with its parts and manufacturer, or you take them separately from the database and put them back together in code. This requires no abstraction. It is exactly what is happening.

dang 8y ago
Could you please stop creating new accounts for every few comments you post? We ban accounts that do this, and it's in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. It's particularly abusive that you used multiple accounts in this same thread. HN is a community. Obviously you don't have to use your real name, but if users don't have some consistent identity for others to relate to, we may as well have no usernames and no community at all. That would be quite a different kind of forum. Anonymity is fine, and throwaways for a specific purpose are ok—just not routinely. https://hn.algolia.com/?sort=byDate&dateRange=all&type=comment&storyText=false&prefix=false&page=0&query=by:dang%20community%20identity https://hn.algolia.com/?sort=byDate&dateRange=all&type=comme...

threeseed 8y ago

> ORMs don't try to make a SQL database something else This is simply not true. Many ORMs are designed to abstract away SQL and RDBMS concepts entirely. They deal in objects and object graphs and output SQL which can be quite disjointed from the object model e.g. many-many relationships.

vinceguidry 8y ago
I'm becoming increasingly convinced that there is only one good ORM and the rest are fit only for CRUD operations. ActiveRecord. The abstraction it provides is amazingly flexible. You can be as close to the SQL as you want to be. With other ORMs, any time I need something not CRUD, I wind up hand-generating SQL. With ActiveRecord, I never need to. Looking at generated SQL, I do all the time with AR, happily it makes that very easy for me. Including my own SQL snippets in scopes? Easy. Hand-generating joins? Almost never.
richmarr 8y ago
> This is simply not true. Providing a wrapper around a thing is not the same as wanting to turn a thing into something else. I would argue that ORMs offer cosmetic change. Convenience, not substantive change. > Many ORMs are designed to abstract away SQL and RDBMS concepts entirely. Which ones? Look at their docs and you'll see where conditions, joins, columns, ordering, aggregations, etc. ActiveRecord is probably the most abstract I've seen and the docs still refer endlessly to tables, foriegn keys, etc and show SQL equivalents http://guides.rubyonrails.org/active_record_basics.html#creating-active-record-models http://guides.rubyonrails.org/active_record_basics.html#crea... Here's Hibernate: http://docs.jboss.org/hibernate/orm/5.3/userguide/html_single/Hibernate_User_Guide.html#fetching http://docs.jboss.org/hibernate/orm/5.3/userguide/html_singl... Here's Sequelize: http://sequelize.readthedocs.io/en/v3/docs/querying/#basics http://sequelize.readthedocs.io/en/v3/docs/querying/#basics Here's SQLAlchemy: https://docs.sqlalchemy.org/en/latest/orm/loading_relationships.html https://docs.sqlalchemy.org/en/latest/orm/loading_relationsh... I would say that ORMs as a class rely heavily on SQL and RDBMS concepts... particularly for anything beyond simple CRUD