Оптимизация с выбранымми

[Grafline]

Как вариант альтернативный тип поля, типа MySQL Запрос можно бес выбиралок зрительных, просто самому туда написать запрос к БД что и как но чтобы его не трогало при обновлении, или галочку в текущее поле - считать в связи или нет.

Может с этой стороны можно подойти как то например завести тип поля объявить его числовым чтоб в формулах работал, и в БД что отключить его от проверки или к чему оно там привязано, так глубоко не знаю.

Тогда да можно проблемные места переписать на свои запросы, хорошо бы с поддержкой пхп а не только MySQL но можно обойтись и им думаю.

Сергей что скажите так может проще можно что то сделать?

[nruslan2]

если вы хотите писать собственные sql запросы и сохранять их в базе, а поле SqL запрос вам не подходит, используйте поле php

ps а насчет инструмента формула (из дополнения) лучше забыть и писать свои собственные запросы.
pps судя по теме у вас реально там что то так криво написано, что при больших обьемах происходят тормоза!! смотрите свои все вычисляемые поля и пробуйте их оптимизировать!

[Grafline]

Спасибо попробую переписать там не криво, достаточно простые решение на 5 - 6 IF максимум плюс округления. Вопрос скорее что выборка с разных таблиц и там тоже свои моменты моменты.

Считал что встроенные формулы шустрее будут чем обычные. Попробую от них отказаться и посмотрю на результат. Ели их удалить то сразу все шустро их достаточно раз в сутки кроном обновлять что и происходит, а вот при каждом изменении сущности можно игнорировать так как они статичны.

Жду ответа Сергея может все таки есть вид поля который не будет дергать при каждом обновлении сущности. Ну или добавить такую возможность для автоматического действия ( обновлять только выбранные поля) Или руками БД их помечать... Вариантов много вопрос как правильней чтоб по минимум упираться в обновления или совсем не конфликтовать с ними.

[nruslan2]

поле php)

несколько if? пример покажите? не могу найти тему но тут недавно кто то спрашивал как упростить конструкцию sql запроса в котором просто куча запросов была с if, надеюсь не ваша так как там 100% было не оптимизировано и бездумно написано!

[Grafline]

Нет давно не писал. Вот простой пример с таблицы 2 ( Пример 10 тысяч записей)

ROUND(if([1]>0,[1],if([2]>0,[2],if([3]>0,[3],[4]*{5}))),2)

1 - Акционная цена если заполнена считаем по ней ели нет смотрим дальше ( числовое поле)
2 - Ручная цена - Красивая например 999.99 если надо указать ( числовое поле )
3 - Цена рассчитываемая отдельно по от закупки, которая рассчитывается от курса юаня и уе и закупки поставщика и доп затрат ( Доп затраты там простая формула но тоже с переменной курсов) ( Доп таблицы Курсы валют к друг другу и приходы, поступления разбитые на поставщиков) - Основная цена
4 - Ручная закупочная ( предполагаемая) Числовое поле - Запасная цена если ошибка основной обычно чуть выше. Предполагаемая цена
5 - Множитель с таблицы 2 - Числовое поле умноженное на процент ( пример 20 - заполняет клиент, делим на 100 по формуле и получаем в значение 0,2) - Таблица 2 имеет в среднем 300 - 600 значений.

Вот этот расчет нужно делать только при обновлении в таблице 3 - поступления или таблице 4 курсы валют. В остальных случаях число статично. А оно мне его дергает каждый раз при обновлении полей количество ( числовое) и Тип ( логическое)

Ну и таких у меня более 10... Некоторые длиннее но там много описывать)

Построено через в поле - MySQL Формула, по вашей рекомендации понял что есть смысл переделать в поле PHP и развернуть запросы руками а не через переменные в [1] и {5} к примеру верно?

[nruslan2]

такой внутренний перебор с if не оптимален
лучше тогда уж case использовать
[] это же значение поля, так что оно и в африке буде значением поля
а вот {} это формула, если она в такой конструкции if используется, то оставить можно и не заморачиваться с переписанием!

в общем пробуйте экспериментируйте) но рекомендую 3.2.1 логипование использовать для проверки! это прямо маст хев в таких случаях

[Grafline]

case у меня тогда вызывал красные криты при пере сохранении, уже и не скажу точно. По экспериментирую может что не так писал...

Радует что прав был что нечего смертельного. Но вот именно на таких обращениях многих к многим в 2 и более связных сущностях все и виснет.
По поводу 3.21 Уже развернул тестовую вношу свои костыли и буду пробовать может еще что покажет... Но суть вопроса та же через PHP поле я так понял также само при любом действии вызывает перерасчет.

Оптимальным решением клон поля MySQL Формула без авто перерасчета или галочка в настройки, или галочка ( функция) В автоматизации считать все, или только выбранные.

[nruslan2]

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

насчет sql формула и sql запрос даже создавал тему в их различиях и они существенны!
viewtopic.php?p=16866#p16866
тоже думал сделать доработку галочку записи в sql формуле, но в итоге передумал viewtopic.php?p=19786#p19786

[Grafline]

Спасибо за совет по 3.21 Вычислил и начал исправлять вот такую проблему

1. Пик торможения это MySQL Формула использующая статичные данные из MySQL запроса ( судя по всему при обновлении пускает в перерасчет) который ссылается на другую таблицу где тоже MySQL Формула, но так как ее нельзя использовать сохранял данные через статический текст.

2. MySQL Формула почему то работает дольше чем PHP динамический
НА простом примере
$output_value = [1]+[2];
Где 1 и 2 это значения с MySQL запросов пример выше.

Работает как поле MySQL Формула что для данных сущностей что для данных родителей + возможность дописыватьс вои запросы тут же без лишних полей в бд уменьшает общую длину запроса.
Такой подход в принципе и есть Формула с записью в базу или нет по галочке и позволяет использовать значение в расчетах...

Также попробую чать MySQL запросов перевести на поле ПХП, чт ото мне кажется что там меньше проверок фоновых все таки.