su.dbms

 
 - SU.DBMS ----------------------------------------------------------------------
 From : Max Antonov                          2:5000/79.101  25 Jun 2003  12:32:58
 To : Eugeney Putilin
 Subject : Репликация
 -------------------------------------------------------------------------------- 
 

 
 24 Jun 03 16:50, Eugeney Putilin wrote to Max Antonov:
 
  EP> From: "Eugeney Putilin" <eugeney@offpoly.ru>
 
  EP> Tue Jun 24 2003 13:57, Max Antonov wrote to Eugeney Putilin:
 
  MA>> Hello!
 
  MA>> 24 Jun 03 10:59, Eugeney Putilin wrote to Max Antonov:
  MA>> Тут я не понял если честно..
  EP>  Hу смысле мне написали что система будет работать как я решу, и 
  EP> напишу. Как
  EP> будто есть вариант когда она будет работать иначе чем решит 
  EP> разработчик. Это
  EP> только глюк в разработке и в используемых средствах.
 
 Понятно.. 
 Я имел ввиду что стандартных средств для решения этих проблем нет, писать их
 каждый раз вручную надо..
 
  EP>>> Hо меня интересует как пишут другие эти функции. Hу есть например 
  EP>>> документ,
  EP>>> или чтото еще аналогичное. Как слить два изменнения в одно причем, 
  EP>>> документ
  EP>>> рассматриваеться целостным по дате последнекго изменения не проходит 
  EP>>> т.к.
  EP>>> может он бы принял эти изменения произошедцишие этом ранее, например 
  EP>>> один
  EP>>> меняет дату другой номер. Все логично и правильно но рабивать 
  EP>>> документ на
  EP>>> кусочки это не правильно.
 
  MA>> Я ничего похожего не писал, но думал на эту тему ;)
  MA>> Тут база данных вообще не при делах, на все случаи жизни решения не
  MA>> существует.
  MA>>  Hапример если мы в процессе слияния имеем доступ ко всем "версиям"
  MA>> документа одновременно, можно путем хитрых процедур это как-то
  EP>  Это есть в видуе поддержки битемпоральности. А ля аудиторский след.
 
 Тут просто битемпоральность не подойдет. Изменения еще и реплицировать нужно на
 остальные сервера. Это теже изменения, опять конфликты. Т.е. собрали версию, ее
 же еще всем другим базам отдать нужно. 
 В общем получается что при слиянии всех изменений мы должны заблокировать этот
 документ на всех серверах, чтобы во время слияния никаких изменений не
 добавилось, иначе эти изменения могут пропасть. А это как-то с постановкой
 задачи немного не вяжется.
 Можно сделать так, что документ будет генерироваться сложной процедурой каждый
 раз "на лету" путем прикладывания всех изменений к начальной версии. Будет
 очень
 медленно, но зато никаких конфликтов: любое изменение - добавление данных.
  MA>> реализовать (их придется отсортировать по времени, потом сливать в
  MA>> порядке очереди, приоритеты там расставить). То есть в какой-то 
  MA>> момент наша суперраспределенная система должна работать как одно целое 
  MA>> (т.е. все ноды должны быть в режиме онлайн). Иначе никак. Hо чаще 
  MA>> всего изменения происходят асинхронно, хочется чтобы вся система 
  MA>> работала асинхронно и т.д., а в таких условиях данная задача не имеет 
  MA>> решения. Можно работать по принципу "кто последний закоммитил, тот и 
  MA>> прав", как например в CVS.
  EP>  Hе подойдет, в CVS раскладываеться по строчкам. В нашей системе высе 
  EP> варианты
  EP> разложения сситемы на кусочки и сливать из них не проходит. Т.к. если 
  EP> один
  EP> меняет дату другой номер. То в конечном варианте может поменяться или 
  EP> обе эти
  EP> записи или какято из них ну и т.д.
 
 Hу тут можно не по строчкам, а по столбцам таблицы раскладывать. Либо еще
 как-то - документ же структуру имеет все равно.
 Если еще разрешение конфликтов автоматическое придумать - вполне может работать
 на мой взгляд.
 
  MA>> В любом случае тут нужно думать над конкретной задачей. Да и вообще
  MA>> редактировать один документ в нескольких местах - плохая идея на мой
  MA>> взгляд.
  EP>  Естноо. Hо людиже както работают.
 
 Hу то люди, а то компьютер ;)
 
  MA>> Лучше уж организовать что-то типа "Документ забрали в наш филиал и 
  MA>> там с ним работают" ;).
  EP>  Это можно. Будет работать но очень длинная, первая репликация запрос
  EP> документа, вторая ответ что забрали, третья что завершили. Еще 
  EP> возврат назад,
  EP> если забыли поменять. Hечто аналогичное есть внутри системы, есть 
  EP> состояние
  EP> проведенного и не проведенного документа.
 
 Про это Denis Gorbunov написал, не хочется переписывать :)
 А вообще можно посмотреть доку от оракла:
 http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96567/toc.htm
 там достаточно подробно расписано что да как. Понятно что рецептов на все
 случаи жизни нет. Если спросят пароль, на www.oracle.com нужно
 зарегистрироваться.
 WBR, Max.
 
 --- Msged/BSD TE 06 (pre)
  * Origin: Operation Mindfuck (2:5000/79.101@fidonet)
 
 

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

Тема:    Автор:    Дата:    Репликация   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