|
su.dbms
- SU.DBMS ----------------------------------------------------------------------
From : Ilya Zvyagin 2:5020/400 07 Jun 2001 12:02:30
To : All
Subject : Re: Informix ?
--------------------------------------------------------------------------------
Sergey Practh wrote in message <9fm2ur$7ft$7@www.kot.poltava.ua>...
>> >> select @lastnum=lastnum from surrkeys with (updlock) where
>> >> tableid=<id> update surrkeys set lastnum=@lastnum+1 where
>> >> tableid=<id> Что то вроде этого, дальше все ясно.
Да не все так плохо.
>1. "Горлышко винной бутылки" - очереь на обновление этого поля;
Можно получение следующего ID делать в отдельной транзакции.
В случае же генерации поля с бизнес-правилами (типа "строго по порядку")
эти правила диктуют serializable.
>2. При решении проблемы 1 - невозможность гарантировать возврата точного
>ПОСЛЕДHЕГО ИСПОЛЬЗОВАHHОГО значения в любой момент времени, для
произвольной
>сессии.
Да зачем его в любой-то момент получать ? Получил один раз в начале - и все.
Hу да ладно.
>3. Если решаются проблемы 1 и 2 - остутствие возможности получения точного
>значения ПК.
>4. Если решается проблема 3, то автоматически возникает проблема 1. Дальше
>все снова по циклу.
Это что-то вообще не понятно.
Короче, только из практических соображений.
У нас база на OLPT стоит в главной своей части ТОЛЬКО на генерации ключа,
аналогичной вышеприведенной. Даже еще хуже, используется тривиальный
select isnull( max(id), 0 ) + 1 from XXXX
таблица главная - ОДHА. Казалось бы, должно быть узкое место, на практике
все же до него дело не доходит, проблемы всегда с чем-то другим.
Короче, в каких-то случаях использование таких подходов допустимо.
--- ifmail v.2.15dev5
* Origin: FCT Saint-Petersburg (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
