Closed sylvesterroos closed 1 month ago
After thinking about it, I think using triggers is not the correct approach here because I don't see the problem with running a simple count(*), while building triggers takes a lot of SQL code and whoever manages the database must be careful to not disable the trigger. Given that the votes table will not be excessively large, I think that we should simply use a join on the votes table whenever we want to know how many votes a wanted has.
You can do materialized view and make code which will update it in Elixir. Views can be connected with Ecto like regular schema so it's nothing special.
Materialized views are often used in big reporting databases. Here we can do a simple join, so why not do just that? Follow KISS
I know, just suggesting better solution than db triggers how you mention.
Materialized views are often used in big reporting databases. Not really big reporting databases, mostly when it makes sense, it depends on data and queries. You can have small data but too complex query with calculation.
This looks good other than the lockfile change.
@bcardarella how do you feel about this though?
After thinking about it, I think using triggers is not the correct approach here because I don't see the problem with running a simple count(*), while building triggers takes a lot of SQL code and whoever manages the database must be careful to not disable the trigger. Given that the votes table will not be excessively large, I think that we should simply use a join on the votes table whenever we want to know how many votes a wanted has.
you want to run count
on every single read?
Oops, clicked review request without seeing you already replied.
Yes, that's what I was thinking. To me triggers seem like unneeded complexity but I'd like to hear your thoughts on it :slightly_smiling_face:
I don't agree
That's settled then. Feel free to merge this PR if the latest changes look good to you
Sorry was on mobile, let me provide more context.
Most app devs tend to shy away from db layer stuff. We app devs do lean heavily into abstractions and APIs and see the SQL itself as verbose and less maintainable. I'd be willing to wager that the trigger code will sit unchanged and undisturbed for quite some time.
Databases are heavily under utilized when it comes to so many tasks that we end up using the application layer for, and usually app layer is far less performant. Embrace the database :)
Will merge, thank you!
Closes #10