ThunderCat

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

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

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

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

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

Часто такая ошибка возникает если жквери 2 раза подключен. Или где-то опечатка в коде.

Учимся ходить в интернет по-большому

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

Куки, локалстораж, сессия, все что может хранить состояние, тут уже от нюансов реализации зависит.
Если у вас форма уходит постом, так и брать из поста.

пхп ини настроить:
default_charset = "utf-8"

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

Работает вроде, в цсс не хватает закрывающего }

Как и везде, есть несколько путей, например:
* Крон каждые 10 минут, это будет не большая нагрузка и не думаю что игровая механика поломается если вещь продастся не через час, а через час и 5 минут.
* Не делать крон, а при очередном запросе списка вещей проверять на наличие "устаревших" шмоток и автоматически менять на деньги. Тогда нагрузка будет более выборочной, "размазанной" во времени, + у вас все равно будет запрос к шмотке, тут ее и обрабатывать, сэкономите кучу запросов и ресурсов.

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

Тут БД явно не нужна.

и

Самое важное сейчас - простая связка с 1С.

(это вообще имхо нонсенс, в смысле простая) и

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

это уже противоречие номер раз. Где вы будете хранить комментарии, цены с 1С, заказы и прочие данные? Не, можно конечно в файлах ), но в любом случае как то обрабатывать их нужно, что вы с ними сделаете калькулятором на жс - загадка ).