| [Форум] [Помощь] [Поиск] [Выйти] |
Добро пожаловать, ![[info]](userinfo.gif){kind=small} User
|
|
|
| ||
| Есть хранимая процедура, собирающая с базы разнородные динамические данные. Она должна возвращать их в виде таблицы. Как это можно сделать без создания таблицы с БД? На текущий момент именно так и делается - создается Таблица, забивается данными возвращается (select * from TempTable) и удаляется. Когда в системе один пользователь смотрит статистику - все ОК, но если двое... |
| ||
| я фигею, дорогая редакция... замечание собственно только одно - если двое в _системе_ не могут одновременно читать таблицу, то это не система, а тра-та-та-та. и вопрос один - что мешает создавать всякий раз другую таблицу, т.е. имя другое давать? |
| ||
| Да, я тоже фигею... Это что ж, вместо временной таблицы используется даже не глобальная временная, а просто создается таблица в БД??? Кто ж тот умный человек, кто не щадит не то, что производительности, но даже и всех канонов сервера баз данных? :) Про другое имя - выход, но тоже экзотический ;) Из теории: каждое создание таблицы есть запись о ней и ее полях в системные таблицы. Что, в свою очередь, означает лок системных таблиц со всеми вытекающими. Не критично, но зачем? О работе с временными данными многое уже написано.. Итак, ответа тут есть три. 1) Если уж хочется извращаться использовать только одну не-временную таблицу, то приделайте в нее поле идентификатора (GUID), который будет уникальным для каждого набора данных. 2) Используйте не-глобальные временные таблицы. Они "видны" только в пределах того контекста, в котором были созданы. Вне этого контекста они не существуют и, следовательно, мешать не могут. Естественно, имя одно и то же в разных контекстах может быть использовано. 3) Используйте в процедуре переменные типа "таблица". Тогда временные таблицы не будут создаваться ни в рабочей БД, ни в tempdb, не будут никому мешать, не будут лочить системные таблицы в момент созданияобновления и вообще все у вас будет хорошо и красиво. Единственное ограничение: ты не сможешь строить временные индексы на этих таблицах, но мне кажется, что они там и не понадобятся. |
| ||
| не Лёш, временная таблица уровня сеанса это обычная практика. а поскольку я придерживаюсь подхода о правильном и верном решении, то и предложил, что предложил. да и сам строитель "систем" сделал это руками, не хватало лишь уникального имени |
| ||
| Patrol - большое спасибо. Реализовал 3 вариант. З.Ы. САНЬКА, лучше больше дела - меньше коментов. Заниматься плодением моря новых таблиц с уникальными именами - хорошо, а удалять их потом? |
| ||
| следите за руками: На текущий момент именно так и делается - создается Таблица, забивается данными возвращается (select * from TempTable) и удаляется |
| ||
| Да, Саш, я знаю, что контекстная временная таблица - обычная практика, сам использую в том случае, когда табличных переменных недостаточно :) Я сказал лишь о том, что таблица должна быть именно временной в этом случае :) Для MS SQL Server это таблица, которая автоматически создается в базе tempdb (а не в основной) и, в принципе, SQL Server сам следит за ее жизненным циклом (умер контекст - умерли все его временные таблицы) :) Кроме того, в разных контекстах можно использовать одно и то же имя таблицы, потому не нужно следить за уникальностью имен. А создание временных таблиц в основной БД считаю злом как по причинам описанным выше (локи, производительность), так и по тому, что если человек делает временные таблицы в основной БД, то он отчего-то не использует стандартные возможности работы с временными данными, которые для этого и придуманы ;) А в том случае, когда недостаточно даже и контекстных временных таблиц (например, временные данные должны сохраняться в течение HTTP-сессии клиента, что подразумевает разные контексты БД), предлагаю использовать одну, постоянную таблицу с дополнительным полем-ключем (например, ID сессии). Тогда вообще не придется никаких таблиц создавать, можно лишь чистить таблицу на предмет "старых" сессий (наприме в момент уничтожения сессии) :) |
Отправил