|
su.dbms.sql
- SU.DBMS.SQL ------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 02 Apr 2001 21:14:00
To : All
Subject : Re: Дремина хитрость 2
--------------------------------------------------------------------------------
Serg Vasiltsoff wrote in message <9aa24a$1tmp$4@dipt.donbass.net>...
>> IDENTITY само по себе ничего не лочит. Как вставлять в саму таблицу - это
>> другой
>> вопрос. Во-первых, вставлять как я понимаю , все равно HАДО. Во-вторых,
>> есть ( даже в MSSQL 6.5 ) row-level locking на INSERT.
>Под понятием "узкое место" я подразумевал именно вставку в одну таблицу,
>логичнее было бы Вам не ссылаться на IRL, а пояснить, каким это "другим
>вопросом" вы собираетесь вставлять без блокировок? В общем случае или есть
>варианты?
Я и имел в виду, что IDENTITY не означает автоматически "узкое место",
а скорее всего наоборот позволяет его избежать из-за отсутствия блокировки
при генерации. При генерации же ключа ( не GUID ) без IDENTITY как правило
требуется SERIALIZABLE чтоб одинаковое значение ключа два раза не
генерировалось.
Вот ровно тот случай, что описан у Drema.
UPDATE SEQ WITH SERIALIZABLE set id = id + 1 where ...
Вот это и будет "узкое место".
Hо в зависимости от условий работы приложения ( которых много и которых я
не знаю ) либо одно, либо другое решение может быть приемлимым, а может
будут
таковыми и оба.
>Вставлять в моем варианте ничего никуда не надо - достаточно присвоить
>каждой таблице свой идентификатор, автоматически комбинация "идентификатор
>таблицы + идентификатор записи" дадут уникальность в пределах системы. Есть
>у Вас какие-то комментарии по _этому_ предложению, то есть по сути _моего_
>постинга?
Hет. Я как бы по этой сути ничего сказать и не хотел.
А хотелось возразить на сентенцию
>> Можно сделать IDENTITY в одной главной таблице. IMHO очевидное решение.
> Да, и получить то, из-за чего и разгорелся спор - узкое место.
т.е. что введение IDENTITY может вызвать появление в системе "узкого места".
>термином IRL там как раз скрывается Insert Row Locking (see
sp_tableoption).
>И оговорок по его использованию достаточное количество есть для 6.5
Я в курсе. Hо мы не знаем условий работы приложений DREM-ы, соответственно
не можем оценить возможность применения в его базе IRL.
Hу ладно, я вижу разговор переходит в непродуктивное русло, поэтому
закругляюсь.
PS Так и не понял, что же такое я не дочитал.
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
