не нужно

Аааа

Блеа, дак вопрос в конец добавь просто)))
(\d+):?(\d+)?

тюю

я перед кавычками ставил
(\d+):?(\d+?)

так а не проще по разделителю explode ?

я упростил регулярку для вопроса

полная такая
/({$types})\s*?:\s*?(\d+):?(\d+)/i

перед кавычками это называется «ленивый квантификатор»

спасибо

пожалста

Привет всем!
  Я пытаюсь как-то правильно организовать расчеты, но ума не приложу как правильно.
  Ситуация такая - есть проект, по нему выдаются зарплаты, расходы и получаются доходы. Нужно вести учет всего этого добра. Зарплаты, расходы и поступления поступают и расходуются разными операциями, которых может быть много.
  Требуется выводить таблицу по всем проектам с указанием по колонкам суммы зарплат, отдельно суммы расходов, отдельно суммы доходов и отдельно разницу доходов и расходов, так сказать прибыль. Проектов может быть много.
 
  И тут собственно вопрос. Как правильно это организовать. То ли тянуть в таблицу проект со связью к зарплатам, расходам, поступлениям, через with, потом через -> sum вычислять их сумму и выводить. Т.е при рендеринге таблицы по каждому проекту каждый раз будут тянуться все данные по поступлениям на лету  суммироваться, считаться и показываться.
 
  Или второй вариант в таблицу проектов добавить столбцы Зарплаты, Расходы, Поступления и обновлять эти столбцы при совершении каждой операции. Т.е выдал зарплату сразу в столбец зарплаты записалось. Соответсвенно так таблица выводится без каких либо отношений и вычислений, просто тянутся уже конкретные значения из бд.
 
  Второй вариант вроде более легкий, и мне в глубине души кажется правильным, но чисто логически получается что я дублирую два раза одни и те же данные и боюсь что из-за какой-то ошибки может так случится что сумма, например, зарплат на счету проекта может отличаться от суммы если сложить все операции по зарплате по проекту отдельно.
 
  В общем всю голову уже сломал, подскажите, пожалуйста как будет вернее и что почитать по теме

Строго говоря рано или поздно ты реализуешь оба варианта, т.к. второй не заменяет первый, а дополняет его. Т.к. детализацию по операциям крайне полезно иметь.
Я бы сказал так - лучше сделать первый вариант целиком, если будут проблемы (для мускуля их не будет ближайшие несколько миллионов записей я думаю), то уже приходить ко второму варианту, который по-умному называется «денормализация»

Проектов и операций много?

Или в ближайшем будущем будет много?

В том то и дело что вроде планировалось не так много, планировалось общими крупными общими операциями добавлять. Но по факту сейчас от этого отказались и фигачат кучу платежей по 50р

в ощщем я б преждевременно не денормализовывал. сомневаюсь, что в ближайшем будущем у вас наберется хотя бы миллион оплат

но тут есть еще эксперты, могут иметь альтернативные мнения 🙂

Спасибо большое за подсказку. Сам так и планировал, но теперь постоянно в голове зудит мысль что все эти вычислительные операции лишние и лучше бы тянуть напрямую.

В своё время делал систему по учету некоторых показателей(около 20 метрик, с древовидной структурой), плюс в том что у показателя была отметка времени
было 2 идеи:
1)одна большая таблица и на каждый показатель свой запрос и соотв чтобы дернуть всё - большой запрос скучей джоинов(прим. дата, метрика, значение)
2)одна большая таблица, но уже с колонками

первый вариант был хорош, но когда заполнил таблицу на 500тыс записей пошли лаги, остались на втором варианте
в итоге это было перенесено в clickhouse после его появления.

Если у вас конкретно в финансы идет уклон то у вас это похоже на екселевский вариант журнала бухучета, его структура простая.

На малых данных первый вариант, который описали вы, подойдет, но потом придется выносить промежуточные результаты в отдельное место, уже исходя из потребностей системы отчета