4 ms·

I sometimes feel in the minority. I love databases. When I work in the Ruby on Rails ORM ActiveRecord I can actually visualize the SQL it is generating in my he

by rietta 6y ago

I sometimes feel in the minority. I love databases. When I work in the Ruby on Rails ORM ActiveRecord I can actually visualize the SQL it is generating in my head and also do all sorts of tricks when needed.

petepete 6y ago
That's the key. ORMs get a bad name but most of the time you just want to display a list of things, or one thing in more depth or maybe create a new thing. ORMs unfortunately, have a habit of getting in the way when you want to do something they don't natively support. When they just ignore things the database provides people just end up reinventing the wheel. Rails' implementation of enums is a good example of this.
- lovegoblin 6y ago
  > Rails' implementation of enums is a good example of this. The advantage of ActiveRecord enums (vs db-native) is that you can change the list of valid values without having to run a whole ALTER TYPE - and all the overhead that would entail in doing without downtime in a production db.
  - petepete 6y ago
    And the disadvantage is that you need to look at the code to understand the data. Some things change infrequently enough for DB native to be the better solution.
    - evsasse 6y ago
      A nice "trick" is to declare your enum column on the database as a string, and your enum in the code as a hash with string values. So you can have self-explained data saved onto the database, and all the niceties Rails gives you from the enum. enum object_type: { review: "review", purchase: "purchase", offer: "offer", reward: "reward" } # OR enum action: TYPES.map { |type| [type.to_sym, type.to_s] }.to_h
      - rietta 6y ago
        Nice! I've done #1, but #2 is a neat trick.
- flukus 6y ago
  > That's the key. ORMs get a bad name but most of the time you just want to display a list of things, or one thing in more depth or maybe create a new thing. If you just need to display a list of things then there's nothing much simpler than: var result = exec_query("select * from things") foreach (var row in result) { //output html or something here } The problem is we decided this was bad and had to add more layers, abstractions, translations and complications in between the database and the output, then we needed tools like ORMs to help with that.
  - rietta 6y ago
    In Ruby on Rails, ActiveRecord has a method called pluck that returns the result set as an array of strings or as an array of array of strings. I've totally done this in areas that need performance. In my experience, if you are concerned with just showing some data you should specify the columns instead of doing a *. ActiveRecord also supports that. So, for the bulk case. ORM is safer than straight SQL and allows for more easily testable business logic. It does not block doing the things you suggest even if it is not the most common approach.

by rietta 6y ago

petepete 6y ago

That's the key. ORMs get a bad name but most of the time you just want to display a list of things, or one thing in more depth or maybe create a new thing. ORMs unfortunately, have a habit of getting in the way when you want to do something they don't natively support. When they just ignore things the database provides people just end up reinventing the wheel. Rails' implementation of enums is a good example of this.

lovegoblin 6y ago
> Rails' implementation of enums is a good example of this. The advantage of ActiveRecord enums (vs db-native) is that you can change the list of valid values without having to run a whole ALTER TYPE - and all the overhead that would entail in doing without downtime in a production db.
- petepete 6y ago
  And the disadvantage is that you need to look at the code to understand the data. Some things change infrequently enough for DB native to be the better solution.
  - evsasse 6y ago
    A nice "trick" is to declare your enum column on the database as a string, and your enum in the code as a hash with string values. So you can have self-explained data saved onto the database, and all the niceties Rails gives you from the enum. enum object_type: { review: "review", purchase: "purchase", offer: "offer", reward: "reward" } # OR enum action: TYPES.map { |type| [type.to_sym, type.to_s] }.to_h
    - rietta 6y ago
      Nice! I've done #1, but #2 is a neat trick.
flukus 6y ago
> That's the key. ORMs get a bad name but most of the time you just want to display a list of things, or one thing in more depth or maybe create a new thing. If you just need to display a list of things then there's nothing much simpler than: var result = exec_query("select * from things") foreach (var row in result) { //output html or something here } The problem is we decided this was bad and had to add more layers, abstractions, translations and complications in between the database and the output, then we needed tools like ORMs to help with that.
- rietta 6y ago
  In Ruby on Rails, ActiveRecord has a method called pluck that returns the result set as an array of strings or as an array of array of strings. I've totally done this in areas that need performance. In my experience, if you are concerned with just showing some data you should specify the columns instead of doing a *. ActiveRecord also supports that. So, for the bulk case. ORM is safer than straight SQL and allows for more easily testable business logic. It does not block doing the things you suggest even if it is not the most common approach.