4 ms·
no. I define it thus. "If I already know SQL why should I have to learn this ORM?" SQL already works and does what I need. What does an orm give me that makes t
by zaphar 15y ago
no. I define it thus. "If I already know SQL why should I have to learn this ORM?" SQL already works and does what I need. What does an orm give me that makes the headache of figuring out when I need to shift to naked SQL worth it? Why try to hide the SQL when its just going to leak out to me in non obvious ways later anyway. That is the authors point as well I think.
- pardo 15y agoAs the parent wrote, an ORM allows you to eliminate a TON of boilerplate. Since most ORMs I've worked with are not really as complicated to learn as you try to make it sound, the trade-off is clear. EDIT: fixed a typo.
- craftsman 15y agoI'm really not trying to flame here, so bear with me. :) It's just that in software, the argument "If I already know A, so why should I have to learn B" isn't really useful. Given that software is often about pushing down complexity, one of our main tools is building a "B" so that we don't have to do "A". I know how to write socket code in C, but I'm glad for libraries that don't force me to think about that level--I can pop up a level or two. Examples continue ad infinitum. On the other hand, I can buy the argument "B isn't really very good at abstracting A; I've tried to use B, and every time I use B, I end up just doing A anyway. So B isn't useful." But with ORMs, my experience isn't so black-and-white. I find them very useful a lot of the time. When I run into problems, I can switch to doing SQL directly. That's an okay tradeoff for me. I can certainly understand if others don't find that tradeoff as useful.
- zaphar 15y agoDoesn't look like a flame to me :-) My point was more B doesn't in my experience abstract A well enough to justify its use in anything other than toy or really simple apps that won't live very long or won't have much maintenance. I don't mind an upfront cost if it means I won't be pulling my hair out at 2am trying to make some database call take less then 10 minutes to complete. (Exaggerating there but you get the idea.) If B doesn't do a great job abstracting A then the time spent learning B feels wasted to me. (Edit : extrapolate to abstract)
- SonicSoul 15y ago"What does an orm give me that makes the headache of figuring out when I need to shift to naked SQL worth it?" ORM has lots of benefits. but having to learn less is not one of them. Biggest one is that you don't need to write/maintain a separate code base (sql) for CRUD operations. that's BIG benefit even if you get to use it on 40% of your database interactions. Something as stupid as not worrying about creating the right data conversions and logical types to store data in, will avoid a ton of bugs from intermediate programmers.
- epscylonb 15y agoThis article was posted ages ago. No one is forcing you to do anything, you can write your own database access layer if you like. Often developers who do this end up using parts of their code across different projects, basically they write their own ORM. Or you can use a pre-built ORM, as far as I am concerned for me this is the saner choice. I really doubt I could write something on my lonesome that is as secure, performant and has the features of ActiveRecord in a non trivial amount of time. But the important part is that whichever path you go down, if your project is growing, complex or needs to scale, you need to know your stack. You need to be able to modify or reconfigure each part. You need to understand at a high level what each part of the stack does, and be able to learn exactly what it does at a low level quickly should the need arise.
- EGreg 15y agoThe answer is: because you often want ONE PLACE through which queries are sent, and you often want this place to understand the STRUCTURE of the query, in order to do things like sharding, for example. Sometimes, this one place is actual a MySQL proxy. Check out ScaleDB, which they just launched - it looks promising. But other times, it will be in your own app. That is the ORM :) But in that case I wonder how often you really need relational data stores. You will actually arrive at some sort of ORM if you start abstracting your CRUD operations into ONE PLACE. Basically ORM is the product of DRY.