dk-web: в пень те шаблонизаторы. Гугл любит минимум лишнего. Любит скорость загрузки, любит скорость отображения контента. Яндекс тоже любит. Так что...
По существу вопроса. Завести таблицу с юзерами (рега подразумевает это, с личными данными, как то: место проживания: id города из базы городов, социальный статус и т.д.). Таблицу мероприятий(название, описание, атрибуты, прочее). Связывающая 2-х колоночная таблица id мероприятия | id юзера. Таблица городов. готовые уже есть: citieslist.ru или www.geonames.org (эта платная, но есть координаты и все такое прочее).
Далее делаем выборку с джойнами из связывающей таблицы и циклом считаем нужную стату + через апи выбранных карт ставим метки на карте согласно координатам городов. Полученный массив сериализуем и кешируем до обновления статитстики(регистрации нового юзера на этом мероприятии или любые другие изменения в любой из таблиц, относящиеся к мероприятию).
П.С,
погорячился с одной таблицей, прошу прощения =)
dk-web: под каждый город таблицу это слишком жестко :D
Типовые фразы типа "приветствие\досвидание" можно оформить в виде шаблона "Добро пожаловать в город {city}" где {city} в скрипте заменять на нужный город. Тогда не придется хранить по сути дублирующие записи, и всегда можно будет добавить новую, если типовая фраза должна будет отличаться.
Эта таблица сродни вашей, просто переведена из горизонтальной в вертикальную.
Можно сделать еще вариант:
city_id | welcome | description | history | ... | goodbye
соответственно ид города | приветствие | описание | история и т.д.
типовые фразы тоже будут в нескольких экземплярах, но таблица будет проще для понимания.
не, просто сами файлы шаблонов в кеше. обработка стандартно происходит. Блоки страниц кешируются как обычно. Т.е. инклюды от шаблонов есть, но нет чтения с диска. Да и OPcache настроен.
плюсану, раньше заморачивался с заучиванием функций. А потом забил. Помимо пхп надо SQL знать, надо JS знать, еще тонну всяких мелочей хотябы на базовом уровне. В пень. Есть гугл, есть маны. Что еще надо? По мне так главное понимать концепции, которые ты собираешься реализовывать, на уровне логики. Ну и трудолюбие.
Виталий Хоменко: прощу прощения, но я точно знаю что мне нужно. Мне нужен контроль урла. По дефолту 404, а что разрешено должно выполняться. Каноникалы не выход.
делать таблицу InnoDb и обновлять массово данные по городу через транзации. Это действие будет происходить раз в пол года, так тчо ничего страшного. Прикрутить кнопку аякса"сохранить" у каждого блока с текстом (или сохранять через пять секунд после редактирования, чекбоксы сразу можно). Естественно редактировать не все сразу списком, а только нужный город.
Иды известные. используйте скрытые инпуты для передачи ид города
все это филькина грамота. Именно для более четкого понимания поисковыми системами придумали микроразметку и ввели секционные теги в хтмл5 (). Однако на практике поисковики с такой разметкой загоняют сайты в глубины топа, когда как тот же сайт с тем же контентом но без такой разметки уверенно держится на первых местах. Вывод на мой взгляд очевиден. Не имея schem'ы и html5 разметки сканируемого документа, даже нынешние поисковики не способны отделить лишний мусор со страницы.
Вадим Егоров: никак. задаются алгоритмы и правила, по которым нужно парсить тот или иной сайт\страниц\группу страниц. Все делается в индивидуальном порядке, поскольку каждый разраб сайта делает все по своему шаблону. Универсальных решений не существует.
да было бы. Однако это сделано для мобил и возможности тыкать "нравится" без регистрации. Проблема в том, что у мобильных операторов не так много айпи, а юзеров, ходящих через них овермного. В итого на одном айпи на моем сайте бывает до пары сотен человек единовременно. Поэтому было принято решение сделать для таких временной интервал между лайками. Вариант с кукисами рассматривался, но ничто не мешает удалять их для накрутки. Хеш ип + юзеагент тоже рассматривался, пришли к выводу что лишняя трата ресурса. А больше ничего и не придумал, толкового =)
По существу вопроса. Завести таблицу с юзерами (рега подразумевает это, с личными данными, как то: место проживания: id города из базы городов, социальный статус и т.д.). Таблицу мероприятий(название, описание, атрибуты, прочее). Связывающая 2-х колоночная таблица id мероприятия | id юзера. Таблица городов. готовые уже есть: citieslist.ru или www.geonames.org (эта платная, но есть координаты и все такое прочее).
Далее делаем выборку с джойнами из связывающей таблицы и циклом считаем нужную стату + через апи выбранных карт ставим метки на карте согласно координатам городов. Полученный массив сериализуем и кешируем до обновления статитстики(регистрации нового юзера на этом мероприятии или любые другие изменения в любой из таблиц, относящиеся к мероприятию).
П.С,
погорячился с одной таблицей, прошу прощения =)