Действительно ли временные таблицы ориентированы на многопотоковое исполнение?
этот скрипт сравнивает Object, Arrays и многомерный массив
function compare(a,b){
var primitive=['string','number','boolean'];
if(primitive.indexOf(typeof a)!==-1 && primitive.indexOf(typeof a)===primitive.indexOf(typeof b))return a===b;
if(typeof a!==typeof b || a.length!==b.length)return false;
for(i in a){
if(!compare(a[i],b[i]))return false;
}
return true;
}
. Первая строка проверяет, является ли он примитивным типом. если он сравнивает два параметра.
, если они являются объектами. он выполняет итерацию по объекту и проверяет каждый элемент рекурсивно.
Использование:
var a=[1,2,[1,2]];
var b=[1,2,[1,2]];
var isEqual=compare(a,b); //true
7 ответов
Для первого случая, нет, это не возможно, потому что #temp является локальной временной таблицей, и поэтому не видимый к другим соединениям (предполагается, что Ваши пользователи используют отдельные соединения с базой данных). Временное имя таблицы искажается к случайному имени, которое сгенерировано, и Вы ссылаетесь на это при ссылке на локальную временную таблицу.
В Вашем случае, так как Вы составляете локальную временную таблицу в хранимой процедуре, , что временная таблица будет отброшена, когда из объема процедуры выйдут (см. "раздел комментариев").
Для второго случая, да, Вы получите эту ошибку, потому что таблица уже существует, и таблица длится столько, сколько соединение делает. Если это верно, тогда я рекомендую проверить на существование таблицы, прежде чем Вы попытаетесь создать его.
Временные таблицы составлены только в контексте запроса или proc, который создает их. Каждый новый запрос получает контекст на базе данных, которая свободна от временных таблиц других запросов. По сути, коллизия имени не является проблемой.
Временные таблицы связываются с сессией, поэтому если различные пользователи выполняют Вашу процедуру одновременно нет никакого конфликта...
Таблицы временного файла локального объема (с единственным #) составлены с идентификатором в конце их, который делает их уникальными; несколько вызывающих сторон (даже с тем же входом в систему) никогда не должны накладываться.
(Пробуют его: составьте ту же временную таблицу от двух соединений и тот же вход в систему. Тогда запросите tempdb.dbo.sysobjects для наблюдения фактических таблиц, составленных...)
Если Вы смотрите в базе данных временных файлов, Вы видите временные таблицы там, и у них есть имена, генерируемые системой. Таким образом кроме регулярных мертвых блокировок необходимо быть в порядке.
если Вы не будете использовать два знака фунта ##temp, временная таблица будет локальна и только существует для того локального соединения пользователю
Сначала давайте удостоверимся, что Вы используете реальные временные таблицы, они запускают с # или ##? Если Вы составите фактические таблицы на лету и затем отбросите и воссоздадите их неоднократно, у Вас действительно будут проблемы с параллельными пользователями. Если Вы - createing глобальные временные таблицы (которые запускаются с ##), у Вас могут также быть проблемы. Если Вы не хотите использование проблем параллелизма локальные временные таблицы (Они запускают с #). Это - также хорошая практика для явного закрытия их в конце proc (или когда они больше не необходимы proc, если Вы говорите длинный многоступенчатый procs) и проверять на существование (и отбрасывание раз так) перед созданием.