I'll try to clarify what I mean, since my reply to the other post is somewhat confused. I should read more carefully before posting. Anyway.
First of all, is your data suitable for storage in a relational database?
If not, if you end up having to do tons of joins and every table has references to other tables, something like Redis is probably a better fit - I'd move away from ORM/relational at that point.
If it is, then what does using an ORM buy you? Simple queries are simple to write and maintain, so in my experience you don't gain much there. More complicated queries are not handled well by any ORM I've seen, so there you'll want to write them in a relational language anyway.
So, at least the situations I've had come up have both resulted in moving away from the ORM, either to a non-relational database or to keep the data in a relational-friendly format. A lot of the nitty gritty of writing relational queries by hand (as noted, escaping, listing the fields to be queried etc) can be abstracted by a set of helper functions, and maintaining these is much simpler than fixing problems with the relational mapping. For example: you have an inefficient join. Using an ORM, you'll be solving this problem indirectly either by massaging the ORM or bypassing it entirely. If your join is directly expressed in SQL, you solve the problem by modifying the join. There's no additional headache involving figuring out how the object model turns into tables and queries.
Data that's not a good fit to be represented as relations is a completely different issue, and I agree with you on that.
Simple queries maybe simple to write, but they're still boilerplate you're better off without. An ORM lets you work at a higher level of abstraction.
> A lot of the nitty gritty of writing relational queries by hand (as noted, escaping, listing the fields to be queried etc) can be abstracted by a set of helper functions, and maintaining these is much simpler than fixing problems with the relational mapping.
Except that you just started to roll your own ORM, and I can guarantee that maintaining it will not stay simple for very long.
> If your join is directly expressed in SQL, you solve the problem by modifying the join.
Yep, that's what you do with a good ORM.
>There's no additional headache involving figuring out how the object model turns into tables and queries.
Wrong - as long as you have a relational DB at one end and an object model at the other, this additional headache is unavoidable.
First of all, is your data suitable for storage in a relational database?
If not, if you end up having to do tons of joins and every table has references to other tables, something like Redis is probably a better fit - I'd move away from ORM/relational at that point.
If it is, then what does using an ORM buy you? Simple queries are simple to write and maintain, so in my experience you don't gain much there. More complicated queries are not handled well by any ORM I've seen, so there you'll want to write them in a relational language anyway.
So, at least the situations I've had come up have both resulted in moving away from the ORM, either to a non-relational database or to keep the data in a relational-friendly format. A lot of the nitty gritty of writing relational queries by hand (as noted, escaping, listing the fields to be queried etc) can be abstracted by a set of helper functions, and maintaining these is much simpler than fixing problems with the relational mapping. For example: you have an inefficient join. Using an ORM, you'll be solving this problem indirectly either by massaging the ORM or bypassing it entirely. If your join is directly expressed in SQL, you solve the problem by modifying the join. There's no additional headache involving figuring out how the object model turns into tables and queries.