7 ms·

If you use a relational database and believe you don't need to know sql, you're delusional. If you are using a relational database, know sql, and want to elimi

by div 15y ago

If you use a relational database and believe you don't need to know sql, you're delusional. If you are using a relational database, know sql, and want to eliminate a TON of boilerplate, use an ORM. I don't know of many ORM's that claim "Use us and you won't have to know SQL". That's just a straw man argument. If you define breaking down in the terms mentioned by the comment you are replying to, you are playing a semantics game to frame the debate to be: this ORM sucks because I can't use it without knowing sql.

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 ago
  As 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 ago
  I'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 ago
    Doesn'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 ago
  This 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 ago
  The 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.
  - gaius 15y ago
    That "place" is called the query optimizer, there's one in every RDBMS. We've done what you call "sharding" (partitioning) that way since the 1990s.
    - EGreg 15y ago
      mysql query optimizer does SHARDING? and it's not a bottleneck? it's shared nothing?
fauigerzigerk 15y ago
You're not just eliminating a ton of boilerplate, you're also eliminating set oriented thinking, which is key to working with relational databases effectively and efficiently. I find ORMs useful for simple CRUD but that's so little of what I do that I mostly don't bother adding a huge framework to my code just to do some CRUD. A set oriented DB API that cuts down on boilerplate is the way to go in my view. And that is simple enough to create on a weekend.
- jrockway 15y ago
  That's just not true, though. Most ORM's I've used use the set as the primitive element. You declare your schema in terms of sets with relationships. Then you join on relationships. So if you want to find all artists whose name contains 'foo' that have released an album that starts with bar, you would write $albums->search({ name => { -like => 'bar%' } })->search_related('artists', { name => { -like => '%foo%' } }). This looks a lot like the SQL that you would write for the query, except that you don't have to write it and marshal the results back to some format that your application understands. And, the object you get back isn't a set of rows from the database, it's a description of what query you want to run. So you can pass this object around and further restrict or expand the set of results you'll get back when you actually start asking for row data. This works out very nicely for things like web applications where the currently-logged-in-user can only manipulate his own data. You can write your model so that it takes the current user and restricts all data to his rows so that your application doesn't even see data that the user is not allowed to see. It's really quite wonderful and something that raw SQL queries simply don't provide enough abstraction to handle flexibly. Ultimately, people dislike ORMs for the same reason they dislike things like CoffeeScript. They're not mentally comfortable delegating code generation to a computer program -- that's their job. And so, they will complain whenever they are looking at code that's not exactly what the lower level of the system will see. But in general, that's due to inexperience rather than actual dislike.
  - fauigerzigerk 15y ago
    I used ORMs for a long time and I have written my own many years ago, so I understand them well and I have learned to dislike them for most tasks. But I should have been more specific in what I mean by set oriented. The point of working with sets of tuples is that you can apply any set operation to a set of tuples and what you get is a set of tuples. You can use selection, projection or union and you still get a set of tuples. The recursive nature of this principle makes it so powerful and simple. Kind of like Lisp. ORMs introduce a conceptual barrier between objects defined by domain classes created at design time and generic containers used to hold the result of projections and aggregate functions. If you join over two classes and project over some of their attributes you lose all the properties of the original classes, including any attribute accessor methods. Same thing with aggregate functions and grouping. Even if the result of a query involving projections or aggregate functions happens to have the exact same attributes as another existing class, you don't get objects of that class and hence none of its methods. The tuples don't compare equal to objects of that class either because they don't share their type. Different ORMs have various features to partially paper over these issues. I don't want to get caught up in a debate about what ORMs can or cannot do because powerful ORMs like hibernate can do almost anything and everything is optional. The point is that they discourage me from working in a set oriented fashion because they make it hugely more complex than it needs to be. They create a conceptual mess and then they want me to learn a lot of tuning techniques to fix what is broken as a result of that mess. It makes no sense to me.

by div 15y ago

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 ago
As 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 ago
I'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 ago
  Doesn'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 ago
This 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 ago
The 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.
- gaius 15y ago
  That "place" is called the query optimizer, there's one in every RDBMS. We've done what you call "sharding" (partitioning) that way since the 1990s.
  - EGreg 15y ago
    mysql query optimizer does SHARDING? and it's not a bottleneck? it's shared nothing?

fauigerzigerk 15y ago

You're not just eliminating a ton of boilerplate, you're also eliminating set oriented thinking, which is key to working with relational databases effectively and efficiently. I find ORMs useful for simple CRUD but that's so little of what I do that I mostly don't bother adding a huge framework to my code just to do some CRUD. A set oriented DB API that cuts down on boilerplate is the way to go in my view. And that is simple enough to create on a weekend.

jrockway 15y ago
That's just not true, though. Most ORM's I've used use the set as the primitive element. You declare your schema in terms of sets with relationships. Then you join on relationships. So if you want to find all artists whose name contains 'foo' that have released an album that starts with bar, you would write $albums->search({ name => { -like => 'bar%' } })->search_related('artists', { name => { -like => '%foo%' } }). This looks a lot like the SQL that you would write for the query, except that you don't have to write it and marshal the results back to some format that your application understands. And, the object you get back isn't a set of rows from the database, it's a description of what query you want to run. So you can pass this object around and further restrict or expand the set of results you'll get back when you actually start asking for row data. This works out very nicely for things like web applications where the currently-logged-in-user can only manipulate his own data. You can write your model so that it takes the current user and restricts all data to his rows so that your application doesn't even see data that the user is not allowed to see. It's really quite wonderful and something that raw SQL queries simply don't provide enough abstraction to handle flexibly. Ultimately, people dislike ORMs for the same reason they dislike things like CoffeeScript. They're not mentally comfortable delegating code generation to a computer program -- that's their job. And so, they will complain whenever they are looking at code that's not exactly what the lower level of the system will see. But in general, that's due to inexperience rather than actual dislike.
- fauigerzigerk 15y ago
  I used ORMs for a long time and I have written my own many years ago, so I understand them well and I have learned to dislike them for most tasks. But I should have been more specific in what I mean by set oriented. The point of working with sets of tuples is that you can apply any set operation to a set of tuples and what you get is a set of tuples. You can use selection, projection or union and you still get a set of tuples. The recursive nature of this principle makes it so powerful and simple. Kind of like Lisp. ORMs introduce a conceptual barrier between objects defined by domain classes created at design time and generic containers used to hold the result of projections and aggregate functions. If you join over two classes and project over some of their attributes you lose all the properties of the original classes, including any attribute accessor methods. Same thing with aggregate functions and grouping. Even if the result of a query involving projections or aggregate functions happens to have the exact same attributes as another existing class, you don't get objects of that class and hence none of its methods. The tuples don't compare equal to objects of that class either because they don't share their type. Different ORMs have various features to partially paper over these issues. I don't want to get caught up in a debate about what ORMs can or cannot do because powerful ORMs like hibernate can do almost anything and everything is optional. The point is that they discourage me from working in a set oriented fashion because they make it hugely more complex than it needs to be. They create a conceptual mess and then they want me to learn a lot of tuning techniques to fix what is broken as a result of that mess. It makes no sense to me.