Первый способ как раз у нас был, как Вы описали. Ветки создавались от dev, потом dev заливался в мастер, но с ростом команды такой способ перестал подходить, потому что в dev мог оказаться не протестированный функционал другого разработчика и мог попасть в прод. После этого перешли на работу с ветками от мастера, и каждый заливает свой функционал в дев для тестирования, потом после теста эту же ветку заливаем в мастер. Судя по-всему действительно, этот способ тоже уже переросли и пора переходить, как написал выше Antonio Solo, на мастер staging и production, и чтобы у каждого разработчика была своя dev ветка.
Спасибо за ответ! Да, я и хочу попробовать именно агрегирование финальных данных, которые уже с большой вероятностью не будут меняться, но пока изучаю тему, поэтому все впереди))
Ну да, согласен, тут нужно хорошо продумать систему кеширования. Теперь понял, что memcache не панацея) Углублюсь в эту тему и попробую найти оптимальный вариант. Может не сразу, но постепенно тоже хорошо.
Нет, данные довольно сложные. Разрабатывается система документооборота. И запрос, который выбирает элементарно договора организации, получается сложный. Так как необходимо так же выбрать счета к договору, подсчитать сумму оплат по счетам, и прочие цифры. Договоров может быть весьма много, порядка 100 и больше. И чтобы выполнить такой запрос, БД требуется немаленькое время. Да и данные по объему выходят за рамки стандартных Char и Int. Поэтому хочется сохранять именно результат выборки для конкретного пользователя, чтобы потом просто по запросу его вытаскивать без обращения к БД лишний раз.
Видимо немного не правильно выразился. Придется отслеживать изменения, связанные с конкретным пользователем, а не во всей таблице полностью.
Система многопользовательская и данные выводятся из одной таблицы, но только привязанные именно к этому пользователю. Поэтому если один пользователь изменил что-то у себя в данных, кеш другого пользователя не должен сбрасываться. А уж тем более кеш всех пользователей (при сбросе кеша встроенной системеы кеширования MySQL).
Ну да, волнует сброс кеша, так как при определенном количестве пользователей кеширование станет бесполезным, и даже сделает ситуацию хуже, так как эти пользователи будут работать с одной и той же таблицей, кеш будет сбрасываться для всех, и соответственно данные каждый раз все равно будут браться из базы, но при этом ещё будет результат запроса помещаться в кеш, и практически тут же сбрасываться.
Про Memory таблицу спасибо, почитаю, но, если я правильно понял, то в такой таблице фиксированный размер полей, и соответственно, для кеширования результатов, возвращающий разный набор полей необходимы свои таблицы?
Большое спасибо! Теперь понял, как в IDE дела делаются) Раньше документировал код, но так как без IDE — в свободном формате, теперь нужно приучиться к правильному формату.
