3 ms·

I have yet to see a data model so complicated that it cannot be modeled in the more frequently used ORMs. I have tables with two dozen FKs that participate in 7

I have yet to see a data model so complicated that it cannot be modeled in the more frequently used ORMs. I have tables with two dozen FKs that participate in 7 or 8 joins and it's still not a problem. You mention all these things and yet in 10 years of experience they have not been a problem for anyone I know. Have you even used a good ORM?

coldtea 10y ago
>Have you even used a good ORM? Well, I've professionally used Hibernate in Java, Django's ORM in Python, and Sequelize in Node. Also used Active Record for (more CRUD-ish) Rails stuff. I'm sure someone will point to some obscure "better" ones (like there's always the "use a different distro" answer to Linux issues), but those are the most commonly used ORMs in their respective environments as far as I know. >You mention all these things and yet in 10 years of experience they have not been a problem for anyone I know. I could anecdotally point to people I know, but let's have a measurable metric: the support forums for those ORMs are chock full of questions and reports for such problems. Besides, the description of what an ORM can handle as if it's impressive, namely several FKs and joins ("I have tables with two dozen FKs that participate in 7 or 8 joins and it's still not a problem")is hardly the pinnacle of data modeling that a modern DB is capable of. Simple multiple FKs and JOINs are nothing, or course an ORM should (and could) be able to handle them (although even there you can see users struggling with performance issues, over eager bring-the-world-in queries, etc).