Неьольшой совет для всех Cms креатеров
 

Многие из нас делают свои CMS системы или форумы или что-то в этом духе. У меня нет своей CMS и я не планирую ее написание. Я против двойников в сети, за уникальность. Но ресь сейчас не обо мне =)))

Хотел поделиться опытом отображения аватаров в комментах. Задача простая и на первый взгляд решается очень просто.
Начнем с того что НИКАКИХ НАХ БД для этого не нужно. Забудте. Писать адрес аватара пользователя и его наличие в БД, все равно что менять цвет текст на странице вот этим вот скриптом.
Проще кидать ее в диру, например, /img/avatars/ с id пользователя... например если зарегается чел с id=465 то его аватар будет по адресу /img/avatars/465.jpg к примеру.
При такой организации хранения аватаров мы не юзаем БД. Что дает нам большой плюс. Но столкнулся с другой проблемой...
Для проверки, есть ли аватар у пользователя, я раньше юзал file_exists(). Т.е. сначала проверяю, закачал ли пользователь аватар. Если нет - подставляю стандартный. file_exists() через какое-то время стало убивать файловую систему =) что и понятно =)) Тем более если аватаров очень много (рекомендуется разбивать диры на поддиры таким образом, чтобы в каждой дире было не более 5000 объектов). Нашел 2 решения, отказаться от file_exists().

1. Прописывать прямой путь до аватара пользователя, точнее путь, где он должен находится, если залит. nginx же, при отсутствии файла (мы вставляем тег <img> при отображении аватар, сооттветственно запрос идет на web сервер), подставляет стандартный. Делается это достаточно просто конфигом nginx`а.

2. Еще более простой и элегантный способ. Как и в прошлом - в <img src= прописывается путь до аватара, где он должен быть. В это же время CSS`ом задаем ледующие параметры к <img> с аватаром. Допустим, все аватары у нас идут с классом avatar (<img class='avatar'>)
Т.е. картинка с аватаром разширяется до размеров 100х100 и в бэк заливается картинка /img/noavatar.jpg. Если чел залил аватар - то поверх бэка появится его аватар, если же нет - аватар будет /img/noavatar.jpg

Вроде все =)

Думаю что быстрее будет, когда известно есть аватар или нет. Пусть это и БД. Если этого нет то по любому проверка наличия картинки займет время.

На второй случай апач вообще разорется в файле с ошибками. Про первый не знаю, но думаю там тоже осова в определении ошибки.

Но воовще говоря есть еще третий способ.

Для всех пользователей заливаем поумолчанию аватар. Тогда у всех аватар будет присутствовать.

С БД всегда уникальный подход. Насколько быстро будет проверка зависит не только от индексов. А, к примеру, насколько часто обращаются к этой таблице, насколько часто изменяются в ней данные и прочее.
Хотя насчет второго способа - ты прав. Апач ругаться будет.
Первый способ точно быстрее будет. Да, в конфиге ты прописываешь условие. Если по данному адресу ошибка - отображаем этот файл. Но это явно быстрее работает, чем запуск php и коннект к mysql. Насчет второго надо подумать, наверника можно как-то отключить запись подобных ошибок в лог.

Предложенный тобой способ тоже универсальный и достаточно простой и эффективный. Впринципе, стандартный аватар гифовый какой-нить простой будет всить меньше кила, поэтому в данном примере избыточность от веса неиспользуемых аватаров можно взять за материальную точку =)))

почему в бд нельзя хранить имя файла с картинкой (при отсутствии пусть там null будет)? тогда при заливке делаем апдейт (сразу исключаем дальнейшие проверки типа file_exists), а для отображения просто не будет делать отдельный запрос к бд, дополнительная колонка в select не сделает лишней нагрузки :)
такой запрос будет всегда:
select nick_name, login, user_posts from users where user_session='tratata';
что мешает сделать сроазу
select nick_name, login, user_posts, kartinka from users where user_session='tratata';
ну и дальше <img src=<?$rows['kartinka']?>> типа того.
хотя "проверка" на стороне клиента очень прикольная :) и ещё думаю не хорошо решать проблемы на более низком уровне (веб-сервера) лучше ограничеваться возможностями пхп.

Сам селект лишний для отображения коментов он в принципе не нужен. Тем более придется делать как у тебя запрос по каждому пользователю.

2 Li4inka
Поднял десяток проектов. Из них крупные и мелкие - не суть. Нигде не хроню сессии в БД, ни на одном проекте, таких запросов никогда не будет =)
И еще по поводу null. Null это, конечно, хорошо, но приводит к потери данных при определенных условиях. Да и потом он немного коверкает смысл реляционных систем и вообще его использовать не советуют.
А насчет низкого уровня... Как ты себе это представляешь? Приходит запрос от браузера. Его обрабатывает web-сервер, в какой-то момент отдает его на растерзание php, тот, в свою очередь, коннектится к бд и решает отображать тебе картинку или нет. В другом случае запрос, пришедший от браузера полностью обрабатывается web-сервером, не запуская php и не коннетясь к БД.

Хотя опять ж этот способ хорошь лишь в том случае, если есть доступ к администрированию сервера.

- здесь скорее всего храниться session_id(), больше ничего...

А зачем? Неужели текстовый поиск делать по базе будешь? =)

а ннм.ру не ты писал?

2nerezus а при чем тут поиск? я и не предлагаю ничего искать по тексту.:) с запросом я переборщил, но суть остается. я хотел сказать, что добавка в селекте одной колонки впринципе работоспособности не изменит, тем более, что запрос у нас возвратит не более одной строки.