да, так.
уникальный индекс я бы не ставил - может, теоретически, выскочить ошибка, в момент, когда путь еще не задан. полнотекстовый тут не нужен. обычный индекс.
главное - не забыть кодировку этому полю однобайтовую задать, а то индекс в 3 раза больше получится.
С помощью jQuery вставить можно только результат выполнения РНР кода. Запросив его AJAX-ом.
Или можно выполнить РНР код сразу, при генерации страницы, но скрыть див с результатом. А потом по нужному событию открыть его. Все зависит от задачи.
ОЧЕНЬ странная идея.
Прикрутить к существующей БД CМS? У которой свои собственные база, архитектура БД, форматы, идеология?
Нужный функционал можно, разве что, написать. Laravel особенно хорош для работы с готовыми базами.
Я недавно писал надстойку над опенсорсным словарем wordnet.
Штатными средствами PDO получить конечный SQL невозможно.
Результат работы через PDO получается РОВНО ТОТ ЖЕ, какой написан в prepare. Если запрос возвращает не то что нужно, значит он неправильно составлен изначально.
"{$_POST["resource_url"]}" - это АДЪ. Рекомендую писать $_POST["resource_url"] вместо этого ужаса.
из коробки эти функции не поддерживают плейсхолдеры. по этой причине большинство пользователей шарашат свои переменные напрямую в запрос и имеют через это неприличную болезнь. Если допилить собственную реализацию плейсхолдеров, то пользоваться можно.
чувакам из Оракла впадлу поддерживать две библиотеки, и от одной тупо отказались. Поэтому сейчас при попытке обратиться к такой функции выдает ошибку, в 7 версии расширение будет удалено из дефолтной сборки, но будет поддерживаться сообществом. Если сейчас давить ошибки уровня E_DEPRECATED, а в будущем собирать руками (как и любой другой модуль) то пользоваться можно.
Что использовать вместо них, в порядке убывания предпочтительности:
Объект объективно функциональнее функции.
Если ты когда-нибудь использовал функции, ты обязательно сталкивался с их неудобствами - невозможностью вернуть больше одного результата, нагромождением параметров, невозможность работать с разным набором параметров и прочее.
Заменив же функцию на объект, все эти проблемы легко решить.
Если же ты функций не писал, то надо начать с них.
параметры не "прячут". Их изначально не нужно передавать через адрес.
img и name надо брать из базы данных
в адресе должен быть только уникальный идентификатор. подсказка: name таким идентификатором не является. поэтому единственное, что обязательно должно быть в адресе - это id из БД. То есть, адрес должен выглядеть, как
test.ru/play/222
и в play.php по этому ид достаются и заголовок и картинка
почему бы не заполнять last_activity одновременно с date_added?
Кстати, $iaDb->all() - очень глупая функция. Сама идея сэкономить себе два слова - SELECT и WHERE - это какая-то адская жадность и недомыслие.
Интересно, как она себя ведет, если WHERE в запросе отсутствует, а, скажем, ORDER BY - есть.
При этом, я уверен, что плейсхолдеры эта функция не поддерживает
