[xShift]

laimas, будете ли вы, Сэр, напрягаться из-за одного запроса перед обработкой всех данных, который будет дефайнить массив в глобальную переменную с хэшами текущего состояния базы?

Чувствую предлагаете вы использовать низкоуровневые функции MySQL для построчной обработки всех ячеек и последующей конкатенации какого-то более простого cheksumm? Нет, медихлорианы мои подсказывают, что мсье бы и знал толк в извращениях, но не стал бы это делать.

~80% активности это просмотр, а значит select. Цифра не случайна и вытекает из того, что большинство запросов создается анонами, ботами.

Один запрос в инициализацию ядра и мы имеем статический кэш. Один чуть более нагруженный inset/update и delete и мы имеем обновление. Одна файловая операция записи на эти уточнения и все чики-пуки.

Насчет триггеров, кстати, какая то там построковая непонятная логика. Пока не проверил, но FOREACH ROWS меня смущает. Наверное даже от три тригера откажусь.

Собсно, сегодня обнаружил, что у меня get comments зациклился и получилось 57 запросов. Оптимизировал - стало 17. Разница выполнения смешная: 0,02 секунды против 0,2 сек.

Исходя из того, что у меня есть свой движок для БД на базе конкатенации запроса абстракций из структурного массива и есть хэлпер, который просто получает то, что нужно по GetData('any_shit') - я просто добавляю автоматику для получения и обновления кэша, добавляю туда же автоматику для сброса и получения статики и больше ни о чем не думаю.

Сосали все Doctryne и ORM потому, что тот же WP жрет 60 запросов без обвязки, а кэш у него говно. А эти DQL вообще нахер не нужны.

Когда Node.JS доживет до своей нормальной БД - я задумаюсь уходить с backend PHP. Нода щас хуже раз в 15, а PHP стает слегка асинхронным.

Вот такой беспонтовый опус про BigData-идиотов.