Здравствуйте!
Вопрос скорее теоретический - интересуют отличия хранения сессий в файлах и БД. 
В чем выгода хранения в БД?

Рыжий, В основном- удобство доступа к чужой сессии.  "Кто online" и протч. решаются в один запрос... В обычном способе нужно еще напрячься и догадаться, где хранятся файлы сессий, чтобы почитать имя юзера из сессии и т.д.

Опять-же, когда я прикрутил чужую капчу к сайту, мне пришлось отказаться от храниения сессий в базе (не очень, впрочем и надо было ;-) ) Так как прикрутить мой датабазный движок в чужой скрипт оказалось довольно сложно-коряво.

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

Почему? Ведь общение php скрипта с базой часто является самым тормознутым местом.

Добавлено через 1 минуту и 18 секунд

Да, тут согласен.

Поверьте, одна табличка с Unique ключом и единственным вариантом выборки из него не даст никаких тормозов. По крайней мере, до 500-1000qps. В то время, как сетевая ФС - потенциальная точка облома, при глюках в которой ваши юзеры будут на одних мордах авторизованы, на других нет и кто еще знает какие глюки словят.
Но, опять же повторюсь - этот вариант удобен при эксплуатации проекта на нескольких веб-мордах.


Шутите? Даже в теории не могу себе представить, для чего необходим доступ к чужой сессии!

Так же, последнее время мода пошла в качестве хранилища данных сессий использовать мемкеш. Почитать можно тут или тут.

IZ@TOP, Чем заводить новую таблицу "Юзеры online", можно хранить сессию в таблице, в которой имя юзера, нужные свойства и протчие вынесены из "текста" сессии в отдельные поля этой таблицы. Ансериализовывать чужие сессии, конечно, не стоит 

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