> 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.

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.

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

Nice! I've done #1, but #2 is a neat trick.

> 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.

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.