Ок, предположим у вас в результате сотни тысяч итем-ов, и их фетчинг действительно занимает какое-то время. Но зачем советовать это ТС-у и приводить такой аналог, когда у него в результате будет максимум одна строка и селект более чем 100% будет происходить по первичному ключу? Ему не нужно сотню тысяч настроек сотни тысяч пользователей, ему нужно двадцать настроек одного конкретного пользователя.
ДЛЕ... не удивлюсь если сайт взломан.
Primary key + ключ на эти четыре поля (если я правильно понял) и все это должно летать.
Да, да, во всем виноват мускуль...
Не очень похоже. А то, что хочет реализовать ТС вполне можно записать в БД как поля таблицы пользователя.
Курсы Попова? Тупая привычка использовать для фетчинга do-while и почти всегда неверная.
http://ru.wikipedia.org/wiki/Join_(SQL)
SELECT p.*, f.* FROM users_fav f INNER JOIN pages_table p ON p.id=f.pageid WHERE f.userid=$user_id
или
SELECT p.* FROM (SELECT pageid FROM users_fav WHERE userid=$user_id) z INNER JOIN pages_table p ON p.id=z.pageid
в подзапросе можно использовать и ORDER, и LIMIT - все будет шустро выполнятся.
А чем не устраивает этот вариант?
А покажите ради интереса структуру БД и запросы при которых умирал mysql.
А тогда тем более нет смысла извращаться. Никакого существенного прироста в скорости не получите, за то в гибкости разработке на оборот сильно потеряете. ---------- Добавлено 09.07.2013 в 18:40 ----------
Один из недавних примеров /ru/forum/800139
NerZool, а что значит исполняет содержимое? Кто исполняет и что исполняет?
Нормальная защита - загружать картинки к себе на сервер или разрешить только с доверенных хостов.
Системы кеширования разные бывают, от частичного кеширования в БД, то полной статике на файлах.
А нагрузку поможет сократить там, где нагрузка есть, и она связана с получением данных из mysql. Зачем это делать там где это не требуется?
Ну раз "в лоб" чо же ТСу не использовать нормальную бд нежели извращаться на файлах?
Если все правильно спроектировать никаких "напрягов" и лишних телодвижений не будет. Если нет - то и файлы не помогут.
Да нормально. Системные в любом случае будете хранить в БД, и пользовательские тоже можно.
В этом нет ничего страшного, тем более если хотите сохраните актуальные настройки и назвать это действительно настройками.
Есть права - чтение, запись и тд.
Есть группы - которые присваиваются нужные права.