3 ms·
Gosh, no kidding. (I sorta disagree about ORMs though -- if you're selecting by ID it's monkey work to write those queries, but anything complex, sure, use SQL)
by serve_yay 12y ago
Gosh, no kidding. (I sorta disagree about ORMs though -- if you're selecting by ID it's monkey work to write those queries, but anything complex, sure, use SQL)
- macavity23 12y agoRight. A good ORM should deal with all your common cases (if not, your schema probably needs improving), and it saves you writing a lot of boilerplate code. For the edge cases where you need complex joins and/or extra performance, don't try and bother with the ORM, just drop to SQL.
- silon3 12y agoAgreed. Also it should be generating queries based on foreign keys/indexes (including joins). Others should not be allowed in an interactive app anyway: developer should be warned/prevented using a "batch" query by accident.