Время рассудит, но я считаю модель не соответствует предметной области. В существующем проекте GROUP BY с фильтром по статусу заказа условно отвечает на вопрос баланса пользователя.
Если есть баланс- значит операции в две стороны, а значит кроме заказов есть еще и оплаты. И вообще заказ, оказанная услуга и платеж три разных сущности. А потом еще появиться что-нибудь. Так что лучше создайте таблицу (например:сущность,дата, +/-сумма), чтобы потом не умирать над мегаалгортимом расчета баланса.
Я логики не уловил. Ваш пост про то как работу выстраивать и я в целом согласен. А у человека конкретная ситуация. Я предполагаю, что люди не хотят голос свой палить.
В этом и архитектурное решение. Ерунду нельзя ввести. Иначе либо Fulltext index либо Elasticsearh к базе присоединять как я подозреваю. Но это уже отдельная военная операция.
Neoline: Соответствует квалификации. У меня вот за 2 месяца поменялось 10 фронтэндерщиков. Фактически один из 10 в состоянии по ТЗ задачу выполнить. У остальных либо код расплывался либо тест не проходил либо ТЗ не соответствовало.
