ThunderCat

гуглим антивирус для сайтов, сами ручками можем поискать в текстах eval и проверить папки на незнакомые файлы.

А какой механизм привязывает координаты к территориальным районам?

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

ajax

echo curl?

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

если все так сложно используйте 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) по клику на любой пункт делать для всех подпунктов стиль неподсвеченный, затем кликнутый меняем на подсвеченный.

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