ThunderCat

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

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

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

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

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

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

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

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

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

file_put_contents(__DIR__ . '/testfile.txt', 'Start ' + $_GET['id'], FILE_APPEND | LOCK_EX);
sleep(5);
file_put_contents(__DIR__ . '/testfile.txt', 'End ' + $_GET['id'], FILE_APPEND | LOCK_EX);

или накапливать данные в переменной, затем заносить скопом.

А пацаны годами один язык изучают до тонкостей, вот дураки то!

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

В .htaccess

php_flag error_reporting = E_ALL
php_flag display_errors = On
php_flag display_startup_errors = On

в коде в первых строчках

echo ini_get('error_reporting');
echo ini_get('display_errors');
echo ini_get('display_startup_errors');
exit();

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

Ну, в нашем царстве все гос сайты пишут на друпале, как ни странно. Он прост как цмс, он модульный и пахнет елкой основан (частично) на симфони 2, то есть почти чистый мвц (подробнее тут). Если ничего не нужно допиливать - готовая цмс - только настроить и картинки поменять. Если что-то допиливать - разработчиков симфонии много, ну, в смысле они есть.
Если все же катать что-то совершенно особенное и свое - ларавел как самый низкий по порогу вхождения, соответственно не очень дорогой в разработке.

В ворпросе не уловил связи между

будет обновляться каждые 2-5 минут или каждую минуту

и

високой нагрузка на базу данны

Нагрузка на базу данных возникает в случае если запросы выполняются медленно (от 0,01 до 1 секунды и более), или в случае 10-1000 и более запросов в секунду. У вас какой случай?

PS: DevMan ты поржать подписался? )

Как проектируются БД для таких сайтов?

1) Четкие названия для каждого поля, на английском (это стандарт, не ленитесь заглянуть в гугл транслейт для перевода, и сами английский подтянете, и выглядит профессионально, за код не стыдно и тд)
2) В полях где можно сделать ограниченное количество вариантов ставится поле типа int и к этому полю связанная таблица справочник. Так по этим полям будет легче и быстрее делаться выборка в случае поиска по фильтру.
3) Varchar используется только там где пользователь вводит что-либо "от руки", в остальных случаях это практически всегда связь со справочной таблицей, в которой перечислены возможные значения.

Что касается еластиксерча, это механизм поиска в текстовых полях, мощный и удобный, но в данном случае избыточный, просто надо нормально спроектировать. Это все равно что сделать кривой медленный код и потом вешать кэширование чтобы хоть как то работало на приемлемой скорости. Типа, "лыжи по асфальту не едут, давайте лыжнику в ж... вставим ракету помощнее!".

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