Многие из нас делают свои 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'>) PHP: .avatar{ width:100px; height:100px; display:block; background:url('/img/noavatar.jpg') no-repeat; } Т.е. картинка с аватаром разширяется до размеров 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 и не коннетясь к БД. Хотя опять ж этот способ хорошь лишь в том случае, если есть доступ к администрированию сервера.
2nerezus а при чем тут поиск? я и не предлагаю ничего искать по тексту. с запросом я переборщил, но суть остается. я хотел сказать, что добавка в селекте одной колонки впринципе работоспособности не изменит, тем более, что запрос у нас возвратит не более одной строки.
2 nerezus ннм слегка не вписывается в рамки cms да и потом я под cms имел введу универсальный публичный двиг. Неверно выразился =(((