[mbell]

This is a pretty standard way to handle counts and doesn't seem to have much to do with redis. In an SQL database you'd just do it with a trigger and your application wouldn't need to know a thing about it.

[avand]

I've never used SQL triggers. We host our Postgres database with Heroku. As a result, I think I've ruled out database level solutions.

On a related note, it feels good to know that everything our app needs to run is in the code base. Back in my C# days, I remember relying on stored procedures that were configured manually at the database level. Rails fights that with migrations and the callback chain too, so I guess that thinking has sunk in for me.

Thanks for the comment.

[mbell]

> We host our Postgres database with Heroku. As a result, I think I've ruled out database level solutions.

What does hosting with Heroku have to do with using a trigger?

> On a related note, it feels good to know that everything our app needs to run is in the code base.

Except the database schema and any additional indexes you need to make it not perform terribly. All basic setup, just like creating triggers.

> Rails fights that with migrations and the callback chain too, so I guess that thinking has sunk in for me.

The problem with doing stuff like this in a callback is that an additional query is sent to the database which can be a big performance problem if the insert load is high. I generally agree that complex logic should be avoided in triggers and is better left in the application code in most cases but incrementing a counter is about as simplistic as you can get.

[avand]

Well thanks for the insights. I'll keep triggers in mind when I come across a problem like this in the future.

[pvh]

For the record, Heroku doesn't affect your ability to use triggers. It's possible our ancient "shared database" infrastructure simply didn't support it, but the new starter tier plans certainly do.