2010-07-15 3 views
0

В нашем веб-приложении мы создаем таблицу сеансов в базе данных для хранения временных данных. Таким образом, временная таблица будет создана и уничтожена для каждого пользователя. У меня около 300 пользователей для этого веб-приложения. Поэтому для каждого пользователя эта таблица будет создана и уничтожена.Что такое альтернативный способ хранения данных temp в таблице temp?

Я слышал, что этот способ дизайна не является хорошим из-за проблем с производительностью. Я использую сервер MS Sql 2005. Есть ли способ временно хранить результирующий набор без создания какой-либо таблицы.

Пожалуйста, предложите мне некоторое решение. Спасибо.

+0

Похоже, вы подразумеваете, что вы создаете постоянную таблицу для временных целей, а не фактическую таблицу #temporary? –

+0

Я создаю таблицу, такую ​​как ; с человеком как { select * from emloyee } Это будет существовать только для этой сессии только вправо? – Manoj

+0

'; с человеком как {select * from emloyee}' называется Common Table Expression (CTE), и на самом деле это не «таблица» или «временная таблица», а только область действия текущей команды. –

ответ

0

I , решение по адресу GenerateData - это то, что вы ищете. Вы можете создавать тестовые базы данных и удалять их по мере необходимости.

0

В зависимости от того, что вы на самом деле делаете (и можете ли вы его реорганизовать), может быть более целесообразным использовать table variables, которые в высшей степени эффективны.

Существует вопрос о том, действительно ли БД является подходящим местом, чтобы даже пытаться сохранить наборы данных, если это полезно для ваших приложений - если вопрос не просто академический, возможно, было бы лучше сохранить представление объекта данных в вашей памяти приложения?

+0

Таблицы Temp на самом деле часто являются лучшими исполнителями, чем переменные таблицы, если набор данных велик. – HLGEM

+0

как это будет сохраняться на нескольких вызовах страниц? –

+1

@KM - Это не так, но я не видел нужды там, что нужно. Честно говоря, если вы сохраняете наборы данных по причинам бизнеса, я обычно делаю это в бизнес-логике, а не в репозитории. – annakata

2

Либо:

использовать одну постоянную таблицу базы данных для всех пользователей, с колонкой UserID для фильтрации

или

просто использовать способность вашего веб-платформы для хранения информации обработки сессии

+0

SOunds, как с дополнительной информацией, что второй, возможно, это то, что он действительно хочет. Отправьте набор данных на веб-платформу и сохраните данные через сеанс. – HLGEM

+0

Но я использую результирующий набор внутри триггера. Внутри триггера я использую временный набор результатов для дальнейшей обработки. – Manoj

+0

@Manoj сказал: «Но я использую результирующий набор внутри триггера», почему, почему вы не упоминали о триггерах в вопросе? вы только затмеваете реальный вопрос, включив в вопрос 'веб-приложение' и' сеанс'. Я понятия не имею, о чем спрашивает ваш вопрос, пожалуйста, отредактируйте свой вопрос, чтобы было более ясно, что здесь происходит! –

1

Звучит так, как будто вы создаете и отбрасываете постоянные столы. Пробовали ли вы использовать реальные временные таблицы (те, у которых имена таблиц начинаются с #). ИЛИ переменные таблицы, если у вас есть небольшой набор данных. Любой из них может работать достаточно хорошо. Если вы используете настоящие временные таблицы, вам необходимо убедиться, что ваш tempdb имеет размер, достаточный для размещения обычного количества пользователей, а темпдб может вызвать задержки.

+0

Вам также необходимо убедиться в том, что соединение с БД поддерживается, или таблица temp будет отправляться на кавычки. Чтобы сделать его немного более мягким, возможно, захотите проверить глобальные таблицы temp. –

Смежные вопросы