4 ms·
Reply to “What ORMs have taught me: just learn SQL”
- webnrrd2k 12y agoI don't find this response convincing... First, in the intro, it sets up a straw man argument -- that a ORM won't fix your remarkably crappy db or object design. No one expects magic, and I don't see how it's relevant. However, sometimes people are given remarkably crappy designs that they have to support, and ORMs make it much more difficult. ORMs are much better when you can start your db from scratch, but not so good when you have an inconsistent or legacy system. I agree with him about the dual schema dangers, though (ie, Objects -> tables or tables -> Objects doesn't really matter once you have a good abstract entity model worked out. It's sometimes tough to work one out, though, and I tend to do it in the DB first) Transactions in an ORM have been a huge problem, so I pretty much do as much as possible in the db through stored procedures, combined with whatever application code necessary to verify everything is moving along as it should. It seems to me that most developers should learn SQL and databases fairly well. They are just so common, and it's not all that much trouble. Once you know how to normalize data and some basic SQL you're well along the way. ORMs have their place in relatively simple projects, but once code passes a certain level of complexity then ORMs cause much more pain than they are worth. It's a classic leaky abstraction -- you end up spending too much time fighting with the ORM. Debugging SQL through an ORM can be a nightmare, too.