2 ms·
The way you're using an ORM is fine. Do you think, though, that ORMs encourage people to delay learning the highly optimized SQL that you acknowledge is sometim
by combatentropy 10y ago
The way you're using an ORM is fine. Do you think, though, that ORMs encourage people to delay learning the highly optimized SQL that you acknowledge is sometimes needed?
I myself have yet to embrace anything beyond what they call a database-abstraction layer, where instead of pg_query and mysql_query, you just have db_query, but you still have to write the SQL. So:
db_query('select id, name from table where foo = :bar').values({ foo: 'bar' });
Is that so much worse than the more involved ORMs that let you write:
db_select([ 'id', 'name' ]).from('table').where({ foo: 'bar' });
- int_19h 10y agoCompared to the example that you gave, it's not. Where the latter becomes more interesting is when the identifiers are no longer string literals, but actual identifiers (i.e. once SQL records are mapped to some kind of tuple, structure or object type in the language). Then you get things such as static type verification, code completion, refactoring etc. Note that this doesn't require a full fledged ORM. True object-relational mapping requires dealing with things such as object identity.
- greenleafjacob 10y agoI think SQLAlchemy is the only ORM I've used that has support for most/all of: - Subqueries - HAVING clause - USE index hint - WHERE ... IN - SELECT DISTINCT - ON DUPLICATE KEY UPDATE - SELECT ... FOR UPDATE The trouble comes when you're using an ORM that has some but not all of the features, then the abstraction falls apart and you need to go down to using SQL anyway.