su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Liliya Huff                          2:5020/400     27 Dec 2002  19:42:33
 To : Pavel V. Pasechnik
 Subject : Re: Синхронизация доступа к БД
 -------------------------------------------------------------------------------- 
 

 > > Апосля рождества нехорошо будить между прочим :).
 >
 > Да ладно тебе :-)
 
 Hифига не ладно :). "меня будить!!!!" :) - цитата.
 
 > Hу ты в своём амплуа ;-) Hи разу коротко ничего не отвечала.
 > Можешь коротко в двух предложениях сказать как это реализовано?
 
 Hет у нее того снапшота который в этом thread так хотят видеть. В качестве
 доп. информации была дана ссылка на то, что у них термин snapshot означает в
 т.ч. Далее ссылки на то, что есть в реализации транзакций, читать все умеют.
 Вот те 4 уровня, оттуда и плясать, вот тебе как работает с одной базой, и
 как с несколькими одновременно. А что есть, и что с ним делать - вот ссылки
 на документацию, благо у ibm она не из худших, вот туда смотреть и решать,
 что из того что есть можно прикрутить наилучшим образом к неонке того вида,
 которую сам в своем приложении задумал. IBM большой толстый и тормозной,
 быстро что-то менять не будет, впрочем как и все остальные, увы, это факт,
 хотя и хочется чтоб оно подругому было; так что работаем с тем что есть на
 практике, а абстрактно рассуждаем, как это говорят... для собственного
 удовольствия.
 
 А абстрактно рассуждать про то, что архитектурно лучше все-таки следовало бы
 с учетом того, "на каких приложениях собственно". В одном вы будуте иметь
 пачку конкурирующих транзакций, которые редко конфликтуют за данные, в
 другом они будут драться практически постоянно - это одна сторона "как
 часто", вторая сторона вопроса есть "где" - что является областью конфликта
 (множество данных непосредственное - то, что имеем согласно определению
 запроса SQL и пр. элементов языка, которые данным запросом вызываются по
 каскаду, а также замыкание множества - то, что в результате реальной
 жизнедеятельности сервера будет определено как множество конфликта, это
 множество очевидно шире, хотя бы по той причине, что доступ постраничный,
 тут уже смотрим что будет у версионника, что у блокировочника - разные
 замыкания будут даже в теории, судьба такой), третья сторона вопроса "как" -
 динамическое изменение области конфликта во время исполнения запроса - раз,
 транзакции - два, распределенной транзакции - три (в результате все равно те
 еще дебри :) ), потому что ничто в этой жизни на практике мгновенно не
 делается, блокировки мгновенно не накладываются и версии мгновенно не
 отрастают :). Список можно дополнять. Во, добавила свои пять копеек в
 абстрактный разговор.
 Хотя в результате сего абстрактного разговора... скорее всего получим, что
 идеальное теоретичское решение, удовлетворяющее сразу все типы хотя бы
 элементарных задач невозможно в качестве подтверждения старой бабушкиной
 истины, что всем мил не будешь :). Следовательно выбираем то, что не так
 чтобы идеально но в то же время не так чтобы плохо, и называем это "хорошим
 решением" :).
 
 > Ладно. Всех с Hовым Годом! А я сваливаю в деревню на недельку...
 
 Всех с Hовым Годом и последующими праздниками!
 
 --
 Regards, Lilya Huff
 --- ifmail v.2.15dev5
  * Origin: home (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор