Добрый день.
Предлагаю добавить возможность создавать технические таблицы, которые будут участвовать в расчетах для уменьшения нагрузки на систему.
Например у нас есть сложный расчет зависящий от множества переменных. Мы создаем запись и параллельно создаётся вложенная сущность (таблица) в которой мы можем организовать хранение данных. Значения при расчете записываются в таблицу и могут комбинаторно использоваться.
Например мы рассчитали закупку материалов, записали. Далее, рассчитали трудозатраты, записали т.д.
Теперь нам надо посчитать, ну например чистую прибыль, собираем, считаем и отображаем в основной записи. При этом, хотелось бы , чтобы конечный расчет производился при изменении того или иного значения, но по факту, а не динамически непрерывно, чтобы снизить нагрузку.
На данный момент, я реализовал это через вложенную сущность, что не нравится?
1. Осталась возможность добавлять записи, а таблица должна быть одна уникальная.
2. Обновление происходит через автоматизацию "Изменить значение", хотелось бы просто обновлять данные.
3. При сложных расчетах, получаются длинные цепочки запросов и их все нужно записывать в таблицу, приходится городить много лишних полей.
Вот так это выглядит.
Таблица для технических нужд.
- Fait
- Инвестор
- Сообщения: 961
- Зарегистрирован: 19 ноя 2020, 17:46
- Имя: Максим Балакшеев
- Откуда: Россия, Златоуст
- Организация: ИП Балакшеев Максим Георгиевич
Re: Таблица для технических нужд.
Так это каждый под свои нужды сам делает такую таблицу...
Просто закрываете всем доступ к ней, и никто ничего не добавит.
К слову, не обязательно делать её вложенной.
Когда много расчётов, грузиться система будет долго, это факт...
У всех разные нужды, и сделать какой-то универсальный инструмент нереально.
У вас очень много формул, вы следите за всеми этими показателями? Есть ли необходимость рассчитывать их каждый раз или некоторые можно считать вообще в другом месте ю, а то и раз в месяц?
Написать код для расчёта - это полдела. Дальше уже нужно оптимизировать, то есть делать такую систему, которая будет и быстро работать, и считать то, что нужно.
Ещё, выборка из БД происходит быстрее по времени, чем записи и перезапись.
Так что в этом плане часть расчётов можно заменить на динамические, работать будет быстрее.
Просто закрываете всем доступ к ней, и никто ничего не добавит.
К слову, не обязательно делать её вложенной.
Когда много расчётов, грузиться система будет долго, это факт...
У всех разные нужды, и сделать какой-то универсальный инструмент нереально.
У вас очень много формул, вы следите за всеми этими показателями? Есть ли необходимость рассчитывать их каждый раз или некоторые можно считать вообще в другом месте ю, а то и раз в месяц?
Написать код для расчёта - это полдела. Дальше уже нужно оптимизировать, то есть делать такую систему, которая будет и быстро работать, и считать то, что нужно.
Ещё, выборка из БД происходит быстрее по времени, чем записи и перезапись.
Так что в этом плане часть расчётов можно заменить на динамические, работать будет быстрее.
- Andres
- Сообщения: 112
- Зарегистрирован: 09 окт 2016, 01:44
- Имя: Andres Orumets
- Откуда: Estonia, Maardu
Re: Таблица для технических нужд.
5 копеек еще докину:Fait писал(а): ↑05 ноя 2024, 11:32 Так это каждый под свои нужды сам делает такую таблицу...
Просто закрываете всем доступ к ней, и никто ничего не добавит.
К слову, не обязательно делать её вложенной.
Когда много расчётов, грузиться система будет долго, это факт...
У всех разные нужды, и сделать какой-то универсальный инструмент нереально.
У вас очень много формул, вы следите за всеми этими показателями? Есть ли необходимость рассчитывать их каждый раз или некоторые можно считать вообще в другом месте ю, а то и раз в месяц?
Написать код для расчёта - это полдела. Дальше уже нужно оптимизировать, то есть делать такую систему, которая будет и быстро работать, и считать то, что нужно.
Ещё, выборка из БД происходит быстрее по времени, чем записи и перезапись.
Так что в этом плане часть расчётов можно заменить на динамические, работать будет быстрее.
Я бы создал "агрегатор данных" - отдельную систему в подкаталоге. И в него по API кидал бы все, что ни попадя: создали юзера - дата создания, имя и еще чего-нибудь. Создали товар - когда и по какой цене? Купили товар - кто, когда и по чем?
А подкаталог называется "statistics", например. Сложно представить, какие данные в будущем пригодиться могут, а тут "опа" и лог за год уже есть. Профит
Плюс статистику пилить любую можно на данных. А без данных и статистики нет...