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.
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.
Some things change infrequently enough for DB native to be the better solution.
enum object_type: { review: "review", purchase: "purchase", offer: "offer", reward: "reward" }
# OR
enum action: TYPES.map { |type| [type.to_sym, type.to_s] }.to_hIf 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.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.