[DASH] Количество запросов в БД

[xor]

Кстати, UpdatedText - это хорошо, но есть ещё один момент - для каждого значения с некоторых пор пишется источник. Это удобно при отладке, но дополнительно грузит БД.

с точки зрения базы данных - запись чего-то ещё в поле в строке таблицы - мизер по сравнению со временем установления связи с базой, блокировкой таблицы, поиском нужной записи в ней, редактированием, разблокировкой таблицы и закрытием связи с бд.
Это я описал выполнение SQLUpdate для примера с грубым упрощением процесса

[Chainik]

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

А ощутимо ли все это ускоряется, при переносе БД в ОЗУ? Помню, вы описывали свой положительный опыт по этому поводу на Win.

[Logrus]

Кстати, UpdatedText - это хорошо, но есть ещё один момент - для каждого значения с некоторых пор пишется источник. Это удобно при отладке, но дополнительно грузит БД.

с точки зрения базы данных - запись чего-то ещё в поле в строке таблицы - мизер по сравнению со временем установления связи с базой, блокировкой таблицы, поиском нужной записи в ней, редактированием, разблокировкой таблицы и закрытием связи с бд.
Это я описал выполнение SQLUpdate для примера с грубым упрощением процесса

для малинок это критично при большем количестве истории раздуванием бд в памяти и перезаписи этой большей бд на флешку

причем в историческом цикле неверно обрабатывает поле соурс и сам смысл от этих лживых данных теряется

[ProxXx]

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

А ощутимо ли все это ускоряется, при переносе БД в ОЗУ? Помню, вы описывали свой положительный опыт по этому поводу на Win.

я никакой ощутимой разници для себя не обнаружил...

[xor]

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

А ощутимо ли все это ускоряется, при переносе БД в ОЗУ? Помню, вы описывали свой положительный опыт по этому поводу на Win.

ускорения не заметил, диск нагружается меньше - для модных твердотельных дисков очень хорошо

[Alexander Znamensky]

Коллеги, добрый день.

Вот тоже пытаюсь снизить количество обращений к БД. Возник вопрос - что лучше использовать с т.з. нагрузки на БД - CRON или таймеры settimeout?

Спасибо!

[SmoKE_xDDD]

Коллеги, добрый день.

Вот тоже пытаюсь снизить количество обращений к БД. Возник вопрос - что лучше использовать с т.з. нагрузки на БД - CRON или таймеры settimeout?

Спасибо!

Лучше использовать "события", а не деркать каждую секунду систему (Крон и таймер по сути работают одинаково, дергают раз в секунду).
Либо если и юзать таймеры, то как можно сильнее сократить интервалы. Например:
В 19:00 вы заводите таймер на 07:00 следующего дня - будет тикать 11 часов - плохое решение.
Можно записать 1 в свойство и при наступлении нового дня ставить таймер если 1. Это простой пример.

[Chainik]

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

В смысле использовать "AddScheduledJob" или "registerEvent"?

[SmoKE_xDDD]

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

В смысле использовать "AddScheduledJob" или "registerEvent"?

Нет. Физические события: открыл дверь.
Например кейс: При открытии входной двери включается свет в прихожей.
Стандартно большинство из юзеров поставит таймер на выключение света через условно 10 минут.
А можно так: открыл дверь - датчик открытия включил свет - записали время открытия двери - датчки движения прислал, что нет движения 600 секунд - выключили свет. Все без таймеров.

Естественно, совсем от таймеров не отказаться, но по возможности сократить.

[Logrus]

Коллеги, добрый день.

Вот тоже пытаюсь снизить количество обращений к БД. Возник вопрос - что лучше использовать с т.з. нагрузки на БД - CRON или таймеры settimeout?

Спасибо!

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

п.с. обращение к бд в других местах, недавно одно ликвидировали, еще циклы с таймштампом, системстатес и пр. мелочи
ваши входные данные и их обработка
в некоторых модулях еще, к примеру пинг онлайн наоверхедили (апдейт дважды на каждую итерацию)