| ▲ | toast0 2 hours ago | |
> I expect someone who uses an ORM to understand SQL well. From experience, I don't. ORMs are usually sold as 'learn this instead of learning SQL'. For many, the ORM creates the tables, alters the tables, and queries the tables; they don't see SQL and they don't know SQL. When that works, it works, but when it falls apart, they have to debug the SQL and the abstraction layer. I'd rather have fewer unnecessary abstraction layers. > If I pull a datetime from SQL there's a lot of value in having a single piece of code handle that datetime the same way across the entire stack. There's value there, datetimes are very complex, but the rest of the stuff it comes with obscures the value IMHO. > Obviously you are encountering code made by people who don't understand this but the problem isn't the ORM. They would have made that mistake with or without an ORM. It's hard to write the kind of complex queries I've seen by hand, and I like to imagine if you out how to do that, you'll also know why it's slow and not need my help... But the ORM is part of the problem, because when you've written bad queries by hand, and I give you a better query (or sequence of queries), it's easy to apply. When you've done it with an ORM, you may not even know where the query is made. | ||
| ▲ | hparadiz 26 minutes ago | parent [-] | |
You can always make the ORM Model based on a view. Sometimes a background job compiling a simple result set table is the appropriate answer. Almost all ORMs boil down their queries down to a single query handler so it's actually super easy to find the query. My ORM for example:
I used to profile all my queries in those two methods but with tools like NewRelic there's no need to slow the code down with profiling cruft. | ||