Мне нравится одно управление сеансом, встроенное в egroupware.В этой системе каждое предпочтение может быть определено тремя уровнями:
- принудительное предпочтение (решение суперпользователя, пользователь фактически его не увидит)
- предпочтение по умолчанию
- определено пользователемзначение
При получении такой вещи для объекта или массива с пользовательскими настройками может потребоваться несколько запросов.На это также могут повлиять пользовательские настройки долгосрочных файлов cookie.
Тогда есть интерес избегать повторения всего этого при каждом запросе, и сохранение конечного результата в файле сеанса - хорошая идея.И с точки зрения безопасности, я не думаю, что есть большая разница между данными, хранящимися в файлах сеансов, и данными, хранящимися в базе данных, все это на стороне сервера, при хорошем администраторе ваши сеансы не будут находиться в одинаковых каталогах для всех приложений., у вас будет каталог приложений, без проблем.
На шаге дальше.Используя определение предпочтений, сохраненных в сеансе, вы теряете возможность изменить этот сеанс, изменив предпочтение по умолчанию или принудительное.настройки будут доступны для продолжительности сеанса.Если это проблема в вашем случае (ну, в большинстве случаев это не проблема), решение - это кэши уровня приложения с хорошей системой тегирования для способа хранения данных в кэше.Затем вы можете удалить все помеченные данные, когда захотите.
Кэши на уровне приложений, такие как кэш APC или memcached, дадут вам быстрый и эффективный способ хранения данных, используя его для сохранения ваших пользовательских настроек.Хорошая идея, по крайней мере, делиться этими данными между несколькими серверами приложений, не используя NFS для обмена файлами сессий.Но реальным решением в таком большом решении было бы использование кеша для хранения сессий вместо файлов.Таким же образом вы могли бы использовать базу данных для хранения ваших сеансов.
С последним пунктом, хранилищем сеансов базы данных, вы можете представить, что все запросы, использованные для построения предпочтений, теперь все содержатся в уникальном запросе, извлекающемсессия из базы данных (которая содержит ваши предпочтения после первого http-запроса пользовательской сессии).Но это плохое решение для большинства баз данных, так как сеансы получают много событий записи, а для таких баз данных, как MySQL, имеющих много запросов на вставку / обновление в таблицу, может привести к проблемам с высокой производительностью (блокировки, очистка кэша запросов и т. Д.).).Таким образом, файловые системы и кэши лучше управляют сессиями.А базы данных хороши для безопасного хранения долгосрочных данных, хранение сессий - не та же проблема, вам нужно что-то действительно быстрое, что вы можете потерять без особых опасений (так как это только разрушит пользовательский сеанс).
Как вы видите, когда я думаю о сессиях, я думаю о чем-то более быстром, чем база данных.Если ваша система не предоставляет более быстрый способ для сеансов, чем для базы данных, я лично считаю, что это системный сбой, это будет работа для системных администраторов.На стороне приложения вы должны рассматривать сессии как более быстрые, чем базы данных.