Хранение пользовательских переменных в базе данных против сессии в asp.net

Question

Я работаю с приложением asp.net, которое хранит большинство данных в базе данных, а не в сеансе.Я задаюсь вопросом о плюсах и минусах каждого из них и о том, какой путь лучше.Например, у вас довольно загруженный сайт, и вместо хранения пользовательских переменных в сеансе существует таблица БД, называемая пользовательскими данными, которая может хранить все пользовательские данные, к которым можно получить доступ с любой страницы, выполнив запрос к базе данных.Какой путь лучше использовать, сеанс или базу данных?

Answer 1

Сеанс (но это сильно зависит от конфигурации сеанса):

• Нет доступа к базе данных или меньше.
• Временное хранилище: вы можете потерять информацию, по крайней мере, после окончания сеанса.
• Возможно, возникли проблемы с безопасностью, в зависимости от того, где вы храните информацию о сеансе
• Не разглашается: у вас могут возникнуть проблемы, если вы используете ферму серверов, один сервер может не иметь доступа к другому сеансу сервера.
• Может не работать, если клиент отключил куки.

База данных:

• Трафик базы данных для каждой обратной передачи, если вам нужна информация на каждой странице.
• Постоянное хранение.
• Информация о клиенте не сохраняется (файлы cookie ...).
• Общий доступ: данные доступны с любого сервера веб-фермы.

Обратите внимание, что вы можете хранить информацию о сеансе в базе данных. Вот почему я использую слово «может» в части сессии. Смотрите здесь некоторую конфигурацию сеанса и возможности

Answer 2

Все, что хранится в состоянии сеанса, исчезнет при перезагрузке домена приложения.

Этого можно избежать, используя обработчик состояния сеанса вне процесса, но это не лучше, чем база данных.

Answer 3

Во многих случаях я использую Session для хранения временных данных о ... ну ... "сеансе".В ASP.NET сессия настраивается.Вы можете использовать in-proc (по умолчанию), который использует память сервера.Вы также можете сконфигурировать сеанс для использования базы данных или инструмента управления сеансом (в случае проблем с памятью сервера или при перемещении в среду кластера / фермы).

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

Сессия использует память сервера.Пока у вас достаточно памяти и вы не находитесь в кластере серверов, это прекрасно работает.Память быстра, поэтому получение и установка данных в сеансе происходит очень быстро и использует нулевую пропускную способность сети.

Сказав все это, в некоторых моих приложениях сеанс настроен на использование SQL.По сути, это то же самое, что использовать базу данных напрямую, но мне не нужно иметь дело с DAL ... просто позвольте фреймворку работать на вас.

Answer 4

Интересный вопрос.Если это данные, которые не важны между сеансами (скажем, последняя просмотренная страница) -> сеанс.Если это данные, которые должны быть постоянными (скажем, пароль) -> база данных.Интересный случай и тот, на который вы, вероятно, ссылаетесь: данные, которые должны быть постоянными, но также часто используемыми (скажем, имя пользователя).Исходя из этого, я склонен копировать те значения из БД в сеанс, которые позволяют мне работать без доступа к базе данных на страницах с тривиальными задачами.