HTML, CSS - бесусловно, для веб-приложения нужны
AJAX как средство подгрузки данных - подойдет
MYSQL как БД - вполне подойдет
Выбор языка программирования особо не важен, так как его задача по большому счету делать запросы к БД и формировать HTML ответы. PHP вполне подойдет, если вы его знаете.
ИМХО.
Никто не мешает движку "изредка" удалять старые сессии при генерации очередной запрошенной страницы.
Это не очень хорошо, но возможно, однако лучше делать по расписанию.
"$place - массив, преобразованный в строку функцией implode (элементы перечислены через запятую)"
Подозреваю что ошибка тут. Если все так как вы написали, то у вас получится position IN ('p1,p2,p3') вместо position IN ('p1', 'p2', 'p3').
Объединять надо не "через запятую", а через ', '
Так сходу лично мне ближе вариант "один пользователь - одна база".
Как минимум это не вызовет вопросом "почему у меня ID заказа/товара увеличивается не на 1 а произвольно".
Вариант "однако одна база на всех пользователей" может вызвать вопросы с масштабированием в будущем.
Есть компромиссный вариант - одна база на N пользователей - решает вопрос с количеством БД и масштабированием.
Ссылки по теме: https://habrahabr.ru/post/110979/ https://habrahabr.ru/company/microsoft/blog/145027/ SaaS: одна БД на клиента, или общая база данных?
У вас в таблице есть поле users_username_unique на который наложен уникальный индекс.
В таблице уже есть запись с users_username_unique = "".
Вы выполняете insert в эту таблицу без указания этого поля, по-этому возникает ошибка - попытка создать еще одну запись с users_username_unique = "".
Не вдаваясь в суть запроса, если нужно ограничить количество и при этом иметь порядок, то надо добавить: ORDER BY msg1.time DESC LIMIT 10
Но что-то мне подсказывает что у вас проблема в запросе, но я никак не могу понять что вы хотите получить.
Попробуйте:
SELECT * FROM msg WHERE frm_id=35 OR to_id=35 ORDER BY time DESC LIMIT 2;
Если вы их выполняли именно в этой последовательности, то ничего странного нет.
В первом случае была перелопачена база, отобраны 20 записей, а во втором случае - все уже лежало в кеше.
Для начала надо через логи вычислить злоумышленника и выяснить по какому URL производится удаление.
Может быть это совсем не тот URL, который вы подозреваете.
С большой вероятностью БД на shared хостинге доступна только локально (localhost).
Проверить можно через telnet sitename.ru 3306
Если сервер ваш, то можно осторожно открыть порт с ограничением по ip (через iptables, например).