3 ms·
Short answer: First one, then the other. A good ORM that abstracts away simple access, querying and database creation can be a godsend during many early iterat
by legostormtroopr 9y ago
Short answer: First one, then the other.
A good ORM that abstracts away simple access, querying and database creation can be a godsend during many early iterations of a project.
Eventually however you may start to hit boundary cases where an ORM is unsuited or generates slow queries. Once you identify slow queries, then drop down to raw SQL to optimize only when you know where to optimize.
- kyrra 9y agoThis is my answer as well (mostly). Earlier in development when you are iterating on your data model and just trying to write a lot of code, an ORM can help move things along quicker. But once your project is more established, well designed tables and well written SQL could have large impact on performance.
- matt_s 9y agoWhen moving from Java to Rails, I tend to think in SQL first, then translate that to Rails' ORM. I didn't really use ORM's in Java, too heavyweight and the stack we had was old. I would go with this approach too - use the ORM until it gets in your way. When the ORM is trying to be 'smart' but ends up having slow queries or N+1 types of things, refactor the code or use raw SQL. Even better is if your ORM lets you use raw SQL in a way where your results are cast into objects.
- majewsky 9y agoSeconded. I like combining a rather small ORM (for simple access patterns like "get object by ID" or "list all related objects") with hand-crafted SQL for complex reports that join many tables together.