ThunderCat

если все так сложно используйте visibility: visible | collapse

Сильно ли отличаются запросы, в плане нагрузки БД если в базе примерно 20 столбцов?

скорее, в таблице 20 столбцов, это раз, во вторых если база грузит проц значит идет выборка без индексов, либо с большим объемом данных. Не вижу здесь замера выполнения селекта, не вижу индексов, не вижу explain от мускуля. На такой задаче это все гадание по кофе и чаю.

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

Есть один весомый аргумент против таблиц (точнее 2, но второй скорее семантического свойства)
Таблица не может быть нормально отрендерена до момента закрытия тега. В силу этого структура табличной верстки ухудшает загрузку страниц, многие об этом не знают, или не помнят, тк не застали эпоху верстки в таблицах и пограничные холивары в эпоху смены парадигмы на "дивную" верстку. И второй момент семантического свойства - таблицами должны отображаться табличные данные, то есть там где у вас колонки/строчки аля прайс - таблица к месту и подходит, только учитывайте длину таблицы в строках, тоже не очень хорошо делать их километровыми портянками, в крайнем случае есть дисплэй тэйбл для блочных элементов.

Я смотрю здесь идет отбор на битву экстрасенсов )
Возьми за правило проверять действия пошагово если что-то не работает, для начала оставь только строку с редиректом, без ифа, далее логично проверить что попадает в условие проверки и тд.

баланс белого и трешхолд?

ps: а можно где-то посмотреть реальную разницу между фоткой и айфоносканом?

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

Да. Не то чтобы он как то бежал впереди планеты всей, но это будет дешевле. И в разработке и в обслуживании.

Вообще связь от сервера к браузеру, а не наоборот не может быть установлена, т.к. технология хттп запросов этого не предполагает. Если есть четкая необходимость 100% ответа от сервера браузеру в момент обновления данных на сервере, существует 3 способа, из них вам тут настойчиво предлагают самый неверный.

1) Запрос аяксом по таймеру( грузит и сервер и клиент, выполняет кучу ненужных запросов, генерируя мусорный трафик)

2) Лонг поллинг запросы - упрощенно - на сервер идет 1 запрос от клиента, который имеет длинный таймаут, сервер держит это соединение открытым до момента когда на сервере появляются новые данные, после чего отдает в запрос эти данные и закрывает соединение, из браузера открывается новое соединение и тд. Искать тут или в гугле long polling.

3) Сокеты, в принципе это те же лонг поллы, только более оптимально обкатанные, обычно на soсket.io и node.js, которые умеют это "из коробки" и не требуют дополнительных настроек сервера как в случае чисто
пхп лонг поллов.

По всем трем видам море информации, можно смотреть статьи типа такой, весь функционал подробно разжеван.

Гуглить биллинг

UPD: Итак, напишу вопрос как я в итоге понял. Есть меню, с пунктами подменю( что нифига не важно ;) ), в итоге необходимо:
1) Аяксом загрузить некий контент (например список блюд из подраздела) и запомнить его неким образом, чтобы не тащить еще раз при клике на данный пункт подменю.
2) Подсветить линк в меню, тот который текущий.

иотго:
1) делать для каждой аякс даты уникальный ключ(использовать тот что меню передает для запроса аяксом), хранить по этому ключу полученные данные в массиве, при клике на меню проверять или есть в массиве такой ключ, если есть не дергать сервер, взять из массива, иначе аяксом и запомнить.
например создать массив menu, у вас же запрашивается id=3 аяксом, вот и пусть что приходит в ответ от сервера будет храниться в menu[3]; далее в следующий раз if(menu[3]! = undefined) получаем значение аяксом, елсе берем что лежит в menu[3];
2) по клику на любой пункт делать для всех подпунктов стиль неподсвеченный, затем кликнутый меняем на подсвеченный.

Ну, почитайте "Ложная слепота" Питера Уоттса, если верить послесловию романа, многие данные взяты из современных статей, с учетом перспектив развития технологий. Там есть пару здравых идей. "Врата" Фредерика Пола тоже весьма здраво описывают варианты такого непотребства ). Все что касается сегодняшней реальности - близко к этой теме не лежит ни одно исследование, окромя, разве что, хранения отрезанных голов в жидком азоте на предмет записи данных в далеком будущем. Или как в футураме - для музея голов ).

Чет я не понял, цель - выйти за планку 1500 бакинских коммисаров не просыпаясь ночью от смсок "все пропало, вайфай не ловит!"? Ну так смотрим биржи на ценник у спецов, у которых выше 1,5к, трудимся в этой области лет этак 4-8 - профит!

и это спрашивает человек задававший вопрос "Остаток от деления числа выдаёт неправильный результат, что не так в моей проге?"? Пхп учите, SQL, попробуйте с фреймворками поработать, а то как в "джентельменах удачи" - переводчиком пойду, английский я знаю...

вроде для автозаполнения нужно кликнуть в какое-то поле, там онблур не сработает?

Начнем с того что сжатия изображений без потерь не работает для уже сжатых файлов, например jpg, png, gif, за редким исключением, когда например гиф или пнг имеют меньшее реальное количество цветов чем задано в палитре. Речь идет о сжатии с потерями, которое хотя и не портит изображение до неузнаваемости, все же вносит серьезные искажения в картинку, как в цветовом плане, так и в плане "зернистости" и "артефактов". Приемлемый уровень сжатия индивидуален для каждого отдельно взятого изображения, и чаще всего отображается в условной шкале "качества" от 1 до 10 (иногда от 1 до 100, просто шаг искажений делают меньше), где 10 - очень малая степень сжатия и высокое качество, а 1 - полный фуфел, в котором не всегда можно угадать о чем вообще картинка. Соответственно, сжать все в папке не лучший вариант, с каждым проходом и пережатием качество падает, даже не смотря на то что мы выставим максимальное качество, через N итераций мы получим фуфло в чистом виде. По этому гугл определяет отношение размера картинки в пикселях к размеру в байтах и выдает рекомендации на основе статистики, сколько примерно должна весить такая картинка, +/- , пережимать или нет. Так что я бы не стал прям вот все картинки в папке так наивно под одну гребенку.

Как написали - сокеты, и есть вариант с лонг поллинг, например тут и здесь, причем я бы больше на комменты в первой статье смотрел.

Это решение в стиле - "давайте на ралли поедем на асфальтовом катке, им мы управлять умеем, и едет не очень быстро, с трассы не вылетим!".

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

if работает в sql запросах, если есть количество выданных книг - count и if в помощь. Решение не даю ибо не интересно будет.

что запрещает их держать в таблице отдельной?