перед mysql_query() вставьте die($update_sql); и проверьте код.
надеюсь где-то там ..... вы фильтруете $_REQUEST, иначе ждет вас большой сюрприз...когда-нибудь, от кого-нибудь..
А как вы думаете? пишите посредника, который будет брать данные со старой базы и добавлять в новую, т.е. в цикле обходите все записи старой базы и добавляете в новую.
Можно при добавлении новости ajax-ом отправлять отдельные слова в базу и выдавать autocomplete(список найденных игр) с возможностью выбора нужной игры.
Иначе - да, придется разделить новость на слова и пройтись по базе.
Если во всех играх присутствует символы английского алфавита, то можно пропускать русские слова - это один из способов оптимизации
в данном случае нужны регулярки для username, password, email , чтоб лишних символов там не было и нет нужды фильтровать ничего, даже для token можно регуляркой проверить в зависимости от того, какими символами он ограничивается.
а насчет самого вопроса - юзайте prepare, где узнали про уязвимости real_escape_string? и что там было написано? можно и им пользоваться
Вряд ли они уже играют роль в оптимизации/продвижении.
В description можно небольшой анонс записать, либо первые 250 символов(mb_substr())
В keywords также можно первые несколько слов вставить(explode(), array_slice(), implode())
Сессии хранятся на сервере, Куки хранятся на стороне клиента, т.е. к сессиям доступ может получить только лишь тот, кто может получить доступ и к самим файлам на сервере, а к кукам доступ может получить сам пользователь, вот они то и не безопасны.
Это нормально, вряд ли у вас там 100500 тыс активных пользователей.
лучше не хранить в сериализованном виде, хотя это зависит от конкретного случае.
а varchar или выше выбирайте с учетом возможной длинны или с учетом fulltext search(если нужен).
Также как и для обычных комментариев О_О
Или если вы не хотите разлучать parent от child , то подсчет делайте только тех комментов, у которых parent = 0
А что вам нужно посмотреть-то? В запросе принцип работы показан же, если есть совпадение, то увеличиваем вес на 1 иначе на 0 и в конечном счете сортируем по сумме веса.
Сохраняете в базе данных текущую дату + 7 дней, ну и все.
Если vip_date > current_date значит статус VIP все еще актуален.
Есть несколько разных вариантов реализаций
Если незначительные отличия, то одна таблица, столбец - type - отталкиваясь от типа творите чудеса, если изменения значительные - то одна таблица с общими данными + type и вспомогательные таблицы для каждого типа(если, конечно, количество типов не 100500)
$field_cat = "1,2,4";
$exploded = explode(',', $field_cat);
$query = $mysqli->prepare('SELECT id FROM Publication WHERE id in (?, ?, ?)');
$query->bind_param('iii', $exploded[0], $exploded[1], $exploded[2]);
$query->execute();
