Как уже правильно было сказано должно быть:
- таблица с постами
- таблица с оценками
- таблица с рейтингом
Прим. Не обязательно таблица, не обязательно база реляционная - для задачи это не играет никакой роли
Эти 3 сущности напрямую ни через одну логику влиять друг на друга не должны, ибо может привести к довольно печальным последствиям.
Что касается транзакций - там много чего интересного может происходить, включая блокировки, но самое главное что не стоит выносить данную логику на соединение клиента - при увеличении размера базы будет расти и время запроса, а там и другие интересные последствия. Но! Есть решение.
Для того чтобы сделать все красиво существуют Message Brokers (RabbitMQ, Kafka, ... да какой угодно в принципе - выбор зависит от требований к системе).
Архитектура такая:
- пользователь оставляет оценку к посту
- оценка сохраняется в базе оценок
- после сохранения в брокера падает сообщение "у поста 12345 новая оценка" (сама оценка для этого кейса не важна, но ее можно тоже указать)
- клиент счастливо идет дальше серфить интернеты, не ожидая обработки всякой логики, которую задумал программист
- на той стороне брокера сидит маленький демон и слушает эти события
- при появлении события демон моментально пересчитывает рейтинг поста и обновляет его в отдельной таблице
- при росте нагрузки на демона ничего страшного не происходит - все сообщения встают в очередь и ждут обработки
- ну, если хочется совсем все быстро обрабатывать - запускаем ХХХ этих демонов чтобы пережевывали за раз больше информации
Вот так. Надеюсь вам поможет такой маленький пример их мира энтерпрайз-разработки