count можно закешировать на некотрое время, чтоб не считать при каждом переходе на страницу.
Про строить карту я не очень увидел проблему. Когда в массивах с объувью и одеждой элементов поровну, тут всё понятно. А когда в одном больше, перекидываешь часть из одного в другой и опять же делаешь по-старому.
Не смотрел код, поленился. Но такое решение будет удовлетворительно работать на больших объемах:
1 - Посчитать общее количество одежды (КОд) и общее количество обуви(КОб), подходящие под условия.
2 - Исходя из этого определить, на какой странице заканчивается первый то, чего меньше.
3 - Если мы просматриваем более раннюю страницу, то два селекта с одинаковым limit и фетчить оба по очереди.
4 - Если мы на странице, на которой закончился один из товаров, то LIMIT законченный товар делается по старым правилам, а новый товар - плюс разницу, необходимую для заполнения дыр.
5 - Если мы на странице, на которой товар уже закончился, то фетчим двойное количество незаконченного товара.
Только надо учесть, что размер страницы для того товара, который больше не одинаковый на каждой странице, а сначала N, потом N + K, потом 2*N, где К - количество недостающих товаров, чтобы заткнуть дыры там, где закончился первый тип товаров, а N обычное количество товара на странице, и поэтому вычисление первой цифры в LIMIT получится чуть сложнее, чем хотелось бы
put обычно для загрузки файлов. И обычно запрещается веб серверами по соображениям безопасности. И при попыске что-нибудь отправить пишут обычно как раз что-то вроде
Можете и дыры заткнуть, и не менять номера старым заказам. Для этого нужно хранить пулл удаленных заказов и при сохранении нового брать ему айдишку из этого пулла. Правда, часть свежих заказов будут иметь меньшие номера, чем более новые заказы.
Лучше конечно заказчику какие-нибудь дыры заткнуть.
Мне тут вспомнился один проект. В нем как-то тоже начал происходить беспричинный segfault. Оказалось, что если в один из файлов добавить пробел/строку/комментарий, то segfault исчезал! Размер файла при сегфолте был ровно 32к. Чуть больше или меньше - и всё в порядке. Ни малейших представлений, как это объяснить - возможно, проблемы с резервированием памяти при подключении скриптов с таким размером, но вот такой случай.
order by (`on` = '1' AND `launched` = '1') desc, (`on` != '1' AND `launched` != '1') desc.
Убрал order by и добился этим нужного порядка вывода и не озадачился - это прям не знаю. Прям мировоззрение мне перевернул.
Без order by порядок вывода будет меняться при одинаковых данных в зависимости от того, на какой платформе запускается запрос, от того, в каком порядке вставлялись данные и даже от текущей нагрузки на систему. (Добавление)
или order by (`on` xor `launched`) asc
month(date) month, sum(value) perMonth, sum(case when weekday(date)= 0 then value end) perSundays, sum(case when weekday(date)= 1 then value end) perMondays,
sum(case when weekday(date)= 2 then value end) perThuesdays,...
FROM tbl
GROUPBY month(date)
как цифры превртить в названия месяцев, Вы догадаетесь
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 4334
