su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Denis Gorbunov                       2:5020/400     24 Jun 2003  19:34:17
 To : Eugeney Putilin
 Subject : Re: Репликация
 -------------------------------------------------------------------------------- 
 

 Hello, Eugeney!
 You wrote to Max Antonov on Tue, 24 Jun 2003 07:59:11 +0000 (UTC):
 
  EP>>> Hе встречал ли кто в сети или в работе такую вещь: варианты поведения
  EP>>> системы при одновременном изменении одной записис в разных
  EP>>> репликациях БД? Интересуют все варианты кроме поасди человека он тебе
  EP>>> рашит что правильно.
 
  MA>> А какие тут могут быть варианты? Все зависит от бизнес-правил. В
  MA>> оракле например пишется процедура, она и разруливает конфликты. Самый
  MA>> простой вариант - кто позже поменял, тот и прав.
  EP>  Спасибо за ответ, аналогично в news.interbase как напишеш так и будет.
  EP> Интересно если это будет подругому чем напишу, это что глюк в БД не
  EP> сооветсвовать правилам запросов?
  EP> Hо меня интересует как пишут другие эти функции. Hу есть например
  EP> документ, или чтото еще аналогичное. Как слить два изменнения в одно
  EP> причем, документ рассматриваеться целостным по дате последнекго
  EP> изменения не проходит т.к. может он бы принял эти изменения
  EP> произошедцишие этом ранее, например один меняет дату другой номер. Все
  EP> логично и правильно но рабивать документ на кусочки это не правильно.
 Обычно так реализуется:
 
 Hекий набор данных может меняться строго только в одной из реплицирующихся
 подсистем.
 Обычно в той, где этот набор данных первоначально создан.
 
 Если требуется поменять этот набор в другом месте, то из этого другого места
 первым делом должен прийти запрос на захват данных (нечто вроде блокировки
 данных по записи, но не на уровне БД, а на уровне бизнес-логики системы).
 А уже потом в этом другом месте производится изменение данных,
 и отсылается сообщение об освобождении (снятии блокировки) данных.
 
 Про слитие 2-х разных изменений в одно - это все очень зависит от конкретной
 задачи и реализуется исключительно на уровне бизнес-логики.
 
 Есть простое тупое решение - одно из 2-х мест изменения данных (одна из 2-х
 распределенных
 реплицирующихся подсистем) всегда имеет приоритет на случай разрешения
 конфликтных ситуаций - изменения, произведенные в другой подсистеме
 будут просто утеряны.
 
 имеет
 --- ifmail v.2.15dev5
  * Origin: Golden Telecom (2:5020/400)
 
 

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

Тема:    Автор:    Дата:    Репликация   Eugeney Putilin   23 Jun 2003 17:58:18   Репликация   Max Antonov   24 Jun 2003 12:05:34   Репликация   Eugeney Putilin   24 Jun 2003 11:59:11   Репликация   Max Antonov   24 Jun 2003 13:57:28   Репликация   Eugeney Putilin   24 Jun 2003 17:50:18   Репликация   Max Antonov   25 Jun 2003 12:32:58   Re: Репликация   Serguei Tarassov   28 Jun 2003 03:01:23   Re: Репликация   Denis Gorbunov   24 Jun 2003 19:34:17