5 ms·
> In my admittedly anecdotal experience, I have found that ORMs are the most useful for the most trivial queries. True, but 'trivial queries' generally cover t
by davesims 14y ago
> In my admittedly anecdotal experience, I have found that ORMs are the most useful for the most trivial queries.
True, but 'trivial queries' generally cover the majority of use cases within your average CRUD application, and that's exactly why ORMs are useful -- you don't end up re-typing 'select bar from fu where id = 1' or 'select * from fu, bar where fu.bar_id = bar.id' etc., etc.
Beyond that, most of the common joins are trivial as well, and can be abstracted away, and a lot of those queries end up being optimized according to known SQL patterns for the common use cases, so you can avoid n+1 and so forth. For these work-a-day queries, ORMs work just fine.
That said, there are tons of situations where ORMs make no sense at all, like complex migrations, large OLAP-style analytic queries, etc. For these, it's important to keep your SQL chops up and know the pitfalls. So, I use ORMs where they work well, and drop into SQL all the time where they don't.
The trick, as with most things, is finding the right balance: don't try to abstract away complex, singular use cases, but also don't duplicate trivial code all over your code base where the ORM has done the work for you.
- crazygringo 14y agoBut ORM's don't actually help for the trivial queries. I generally find myself writing functions to automate the trivial ones: get_single_field_by_primary_key(), get_row_by_primary_key(), get_values_by_field(), etc. There are maybe 4 or 5 of these. An entire ORM is total overkill. As for the common joins, in my experience they rarely are that trivial. Sometimes it's a left join, sometimes an inner join. Sometimes there's a limit or not. Sometimes there's an aggregate function. If you find yourself writing the same query structure 20 times, then create a function for it. But I've never found that to be the case in projects I work on. I just personally find that ORM's are total overkill in the situations where they can be usefully applied. So the disdain for them kind of makes sense.
- gnaritas 14y ago> I generally find myself writing functions to automate the trivial ones: get_single_field_by_primary_key(), get_row_by_primary_key(), get_values_by_field(), etc. There are maybe 4 or 5 of these. An entire ORM is total overkill. Making a homebrew data layer isn't avoiding an ORM, it's building one. > If you find yourself writing the same query structure 20 times, then create a function for it. What do you think ORM's do? That is what they do, they provide a standard API for all the common queries.
- crazygringo 14y agoNo, ORM's provide object-relational mapping, and all sorts of functions for building up queries as part of that. They don't provide an API for common queries at all. I don't even know what "all the common queries" would be... beyond get-a-value-for-pkey, every app is totally different in the kinds of queries it needs. What I described isn't a homebrew data layer or building an ORM, it's just a few helpful shortcut functions for queries.
- ubernostrum 14y agoI hate to break it to you, but there are about as many definitions of "ORM" as there are of things like "functional programming". What you have described would be considered, by many ORM critics, to be ORM.
- crazygringo 14y agoAw, MAAAAN... Oh well, OK...
- gnaritas 14y ago> every app is totally different in the kinds of queries it needs There is more to SQL than queries. Every app need insert, updat, and delete, and a basic select 1 and select many matching a predicate. Those can all be automated; that's what ORM's do, they automate the repetitive simple stuff. More complex queries that strain the ORM's abilities can be done in SQL in a view, and then mapped in by querying the view with the ORM. Or you can just drop into raw SQL when necessary. Every app is not different, they are largely all very similar.