Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Александр Гoлдун
Тем, что на разных рабочих местах одной БД можно легко отследить текущее состояние документа, например правится ли он сейчас соседом. Проведи аналогию с бумажным документом. Написали что-то на бумажке, протянули руку и передали соседу - он что-то дописал или исправил, вернул обратно и т.п. Все происходит быстро, в определенном приближении это можно считать одновременной работой над документом.

А если сосед в другой комнате? А если в 40 метрах в другом здании?
Александр Гoлдун
А теперь представь ситуацию,
когда не протянул руку с бумажкой, а отправляешь курьера, который
доберется минимум через час.

Ну так в том же примере можно контролировать целостность изменения на уровне документа. Например принимать изменения в документе, только одной из сторон (во всех строках всех таблиц относящихся к этому документу). И писать об этом - напр. в накладной №29 от 10.10.2005 изменения такого-то отклонены, или предлагать изменения на выбор внести. Смотреть, менялись или нет связанные с ним документы, допускают ли они изменение существующего документа и т.д.

Александр Гoлдун
Ну, везде есть недостатки и достоинства. Из всего, что я видел ианализировал, для решения задач с которыми я сталкиваюсь более всего подходит ASA, причем с большим отрывом. В других условиях возможно подойдет что-то более другое, но в плане поддержки репликации, особенно offline, многими ASA признается лучшим выбором.

А я и не говорю, что она не подходит. Просто когда говорится, что
ASCRUS
Для реализации репликации любого уровня сложности в ASA все необходимое уже есть

звучит похоже на знаметиное Билла Гейтса 640 килобайт хватит всем и всегда, как по сути так и по содержанию.
25 янв 06, 16:08    [2286991]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Марк, а я утверждаю из личного опыта, а так же опыта своих коллег. Не знаю, что там Билли или Ларри говорили, не имея еще на руках реально работающего ПО, но как бы приведенные мною возможности ASA показывают, что на функциональном уровне реализации репликаций все необходимое есть. Если есть какие то сомнения в недостающей функциональности, то я всегда готов ответить на вопросы, поэтому мне не понятна, в чем Ваши сомнения. Это мне напоминает сомненья типа, у нас этого нету, значит этого нигде нету, что не раз демонстрировалось на различных форумах SQL.RU. Хорошо, лично для Вас я переформулирую: ASA в области двусторонних оффлайн репликаций умеет не хуже и в некоторых планах лучше решения, чем решения производителей других РСУБД. Такая формулировка подойдет ?
25 янв 06, 16:38    [2287170]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Локшин Марк пишет:

> А я и не говорю, что она не подходит. Просто когда говорится, что

>> ASCRUS
>> Для реализации репликации любого уровня сложности в ASA все необходимое
>> уже есть

> звучит похоже на знаметиное Билла Гейтса 640 килобайт хватит всем и
> всегда, как по сути так и по содержанию.

Ну, мозгов системного архитектора в коробку с дистрибутивом ASA не
кладут. За то можно избавиться от повторного изобретения великого
множества велосипедов: начальная синхронизация, распределение областей
видимости, прозрачный для разработчика транспортный уровень - FTP,
e-mail, file sharing, VIM и оленья упряжка с дискетами. Контроль
целостности сообщений и последовательности сообщений, корректная
автоматическа отработка потерь сообщений, специальный тип триггеров на
разруливание конфликтов, глобальные автоинкременты для упрощения
разделения уже работающих баз и многое другое. ASCRUS именно это и имел
в виду, когда говорил "все необходимое". Просто приходилось сталкиваться
с самописками, в которых все эти вещи люди пытались реализовать сами.
Насколько мне известно, для ASA не пишут сторонних репликаторов, ибо
штатных возможностей более чем хватает.

Posted via ActualForum NNTP Server 1.3

25 янв 06, 16:43    [2287193]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
Все таки Вы Марк путаете бизнес-логику и реализацию. По определению один документ не могут одновременно править два человека, ибо только один из них имеет зафискированный оригинал, с которого шли исправления (если они конечно ксерокопией его не размножили). А вот если документ составной, то его дочерние документы вполне могут править разные люди, наглядный пример - юрист заключил с клиентом договор на покупку недвижимости и расписал плановые платежи по рассрочкам и ссудам. В процессе работы с документом другие юристы вносили дополнительные соглашения к договору, фиксируя их документами. В отделе платежей по пришедшим платежам фиксировалась платежки, пришедшие от клиента. Аналитики использовали информацию для построения отчетов и выявления неплательщиков, с передачей данных юристам для выставления пеней. Поэтому мне странно представить себе одновременную правку одного документа что через онлайн в сети, что в оффлайне через репликации, это явное нарушение технологического процесса, которое сразу начинает ассоциироваться с автоматизацией бардака.

Никакая это не автоматизация бардака. Привожу конкретный пример.
Есть центральный офис. Есть склад. В центральном офисе дают разрешение отгрузить Иванову 1000 ед. товара. Иванов берет пять машин и едет на этот склад забирать товар на 5 машинах, допустим с этим разрешением. Ему отгружают в эти 5 машин товару, допустим по 100 единиц, а когда ТТН оформляли - одну строку пропустили. Уехал он со своим товаром. На следующий день в центральный офис. Давайте мне счет-фактуру. А счет-фактура выписывается только на основании отгрузки, т.е. той ТТН, которая ночью, допустим, попала в центральный офис. А там 4 строки. Что делать? Говорить - звиняйте, завтра приезжайте, сейчас нам подправят на складе, а завтра к нам изменения только дойдут? Изменять на месте? А если на складе обнаружат, что не верно ввели, но данные уже отправлены?
ASCRUS
Вот и я про тоже - не нужно путать бизнес-логику с физической реализацией. Момент изменения документа на двух удаленных узлах одновременно - это организационный момент и решается на уровне ТЗ с заказчиком, а не принципом, пущай сама репликация разруливает.

Дык когда разрывы между сеансами связи могут достигать нескольких дней (ну паршиво работает канал связи). И что в таком случае делать? Я считаю - что такая "подокументная репликация" в таком случае - вполне неплохой выход. А другой выход какой? Не прибавлять же в каждом отчете "в уме" эту недовведенную строку пока она не будет доставлена в очередном сеансе связи.
25 янв 06, 16:54    [2287244]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

кНЙЬХМ лЮПЙ ОХЬЕР:
> мХЙЮЙЮЪ ЩРН МЕ ЮБРНЛЮРХГЮЖХЪ АЮПДЮЙЮ. оПХБНФС ЙНМЙПЕРМШИ ОПХЛЕП.
....
> НРЦПСФЮЧР Б ЩРХ 5 ЛЮЬХМ РНБЮПС, ДНОСЯРХЛ ОН 100 ЕДХМХЖ, Ю ЙНЦДЮ ррм
> НТНПЛКЪКХ - НДМС ЯРПНЙС ОПНОСЯРХКХ. сЕУЮК НМ ЯН ЯБНХЛ РНБЮПНЛ.

йЮЙНИ ФЕ ЩРН МЕ АЮПДЮЙ?
ю ЖЕМШ ЙКХЕМРС РНФЕ ЙКЮДНБЫХЙ МЮГМЮВЮЕР?

Posted via ActualForum NNTP Server 1.3

25 янв 06, 17:02    [2287292]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

Локшин Марк пишет:

> Никакая это не автоматизация бардака. Привожу конкретный пример.
....
> отгружают в эти 5 машин товару, допустим по 100 единиц, а когда ТТН
>оформляли - одну строку пропустили. Уехал он со своим товаром.

Какой же это не бардак?
А цены клиенту тоже кладовщик назначает?

Posted via ActualForum NNTP Server 1.3

25 янв 06, 17:03    [2287300]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
Марк, а я утверждаю из личного опыта, а так же опыта своих коллег.

Ну так из этого вы можете только утверждать, что для тех задач, которые Вы со своими коллегами делали ASA было достаточно.
ASCRUS
ASA в области двусторонних оффлайн репликаций умеет не хуже и в некоторых планах лучше решения, чем решения производителей других РСУБД. Такая формулировка подойдет ?

Такая - конечно пойдет (возможно следовало только уточнить - известных Вам производителей :) ), но все и всегда - это уж слишком.
А шире, чем в ASA я тоже не видел возможностей репликации.
автор
Просто приходилось сталкиваться с самописками, в которых все эти вещи люди пытались реализовать сами. Насколько мне известно, для ASA не пишут сторонних репликаторов, ибо штатных возможностей более чем хватает.

Да самому приходилось такую писать. Но тогда же и показалось, что для "любых случаев" ASA не хватит.
25 янв 06, 17:12    [2287339]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Александр Гoлдун
Какой же это не бардак?
А цены клиенту тоже кладовщик назначает?

Естественно не кладовщик. Цены - в разрешении на отпуск.
25 янв 06, 17:15    [2287354]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Локшин Марк
Никакая это не автоматизация бардака. Привожу конкретный пример.
Есть центральный офис. Есть склад. В центральном офисе дают разрешение отгрузить Иванову 1000 ед. товара. Иванов берет пять машин и едет на этот склад забирать товар на 5 машинах, допустим с этим разрешением. Ему отгружают в эти 5 машин товару, допустим по 100 единиц, а когда ТТН оформляли - одну строку пропустили. Уехал он со своим товаром. На следующий день в центральный офис. Давайте мне счет-фактуру. А счет-фактура выписывается только на основании отгрузки, т.е. той ТТН, которая ночью, допустим, попала в центральный офис. А там 4 строки. Что делать? Говорить - звиняйте, завтра приезжайте, сейчас нам подправят на складе, а завтра к нам изменения только дойдут? Изменять на месте? А если на складе обнаружат, что не верно ввели, но данные уже отправлены?

Самое интересное, что данная ситуация решается обычными административными мерами. В любом случае в центральном офисе после обнаружения неправильной ТТН позвонят на склад, ведь так ведь ? В любом случае на складе поднимут ТТН и сверят с данными в программе ? В любом случае для правильного оформления в центральном офисе им придется по факсу или телефону выслать правильные данные, которые вобьются в центральном офисе и вниз спустяться на склад во время следующей ночной репликации. Это наиболее вероятная ситуация. Рассмотрим более нестандартную и маловероятную ситуацию (во всяком случае в моем представлении) - ночью прошла репликация и кладовщики вдруг с какого то перепугу вдруг вспомнили, что они что то неправильно оформили и вбили это в программу. Соотвествующе данные попадут только на следующую ночь, а клиент уже приехал в офис и жаждет счета фактуры. Ок, раз есть такая ситуация, значит и в структуре БД необходимо предусмотреть пути ее решения. В таблицу ТТН добавляем флаг IsLocal, на фильтр репликации вешаем IsLocal = 0 и на триггер добавления записей вешаем удаление из таблицы записи с IsLocal = 0, по номеру строки равному номеру вставляемой из репликации записи. В итоге ночью придут оригинальная строка со склада, автоматом удалит временно введенную строку в офисе, однако это удаление не отобразится в репликации и на склад удаление этой строки не пойдет. Следующая ситуация - в офисе и на складе поменяли одни и те же существующие записи. Тут мы спокойно все сможем урегулировать, написав триггер на конфликт версий, в котором может определить, чью строку считать правильной, а чью откатить до состояния правильной - по последней дате изменения, по приоритету что здесь складская информация является оригинальной, и т.д. Так же никаких сложностей. Хотя лично считаю, что пример притянут за уши и я бы на самом деле после отпуска машины со склада блокировал флагом документ на складе, чтобы его изменить мог только офис, как более приоритетная организация, решающая вопросы таких ошибок, во избежания ошибочных ситуаций и увода от отвественности кладовщиков, допускающих такие серьезные ошибки.
25 янв 06, 17:18    [2287360]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
В любом случае в центральном офисе после обнаружения неправильной ТТН позвонят на склад, ведь так ведь ? В любом случае на складе поднимут ТТН и сверят с данными в программе ?
ASCRUS не уподобляйся декаблистам и Герцену!... Будь ближе к народу!...
шутка
25 янв 06, 17:42    [2287474]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Все проще, реально у меня есть понимании ситуации - как никак если посмотреть на оформление ГТД начиная отпуском от постов и завершая завершением оформления на таможнях, с параллейным движением платежек сверху вниз к таможням, да еще с почетным кругом через наличку - то есть задачки и посложнее ситуации с недобросовестными кладовщиками, однако в любом случае любой процесс требует документрирования и четкого разграничения на административном уровне что прав доступа, что ситуаций изменения информации в пути, что прочих неприятных ситуаций. Иначе можно и правку закрытого опердня в банке разрешить, мало ли, оператор ошибся, а утром вот вспомнил ;)
25 янв 06, 17:57    [2287522]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
gardenman
Member

Откуда: С-Петербург
Сообщений: 2347
Целиком согласен с ASCRUS.
Но вот всеже в случае с ГТД, или с теми же полисами ОСАГО - проще полностью весь документ один раз передать чем реплицировать полсотни табличек, на которые этот догумент разложен много-много раз. разументся ИМХО.
25 янв 06, 19:16    [2287768]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
В любом случае для правильного оформления в центральном офисе им придется по факсу или телефону выслать правильные данные, которые вобьются в центральном офисе и вниз спустяться на склад во время следующей ночной репликации.

А если связи не будет несколько дней?
ASCRUS
Рассмотрим более нестандартную и маловероятную ситуацию (во всяком случае в моем представлении) - ночью прошла репликация и кладовщики вдруг с какого то перепугу вдруг вспомнили, что они что то неправильно оформили и вбили это в программу

Не с какого-то перепугу, а допустим когда делает оборотную ведомость по складу, смотрит, что у него что-то не то.
ASCRUS
В таблицу ТТН добавляем флаг IsLocal, на фильтр репликации вешаем IsLocal = 0 и на триггер добавления записей вешаем удаление из таблицы записи с IsLocal = 0, по номеру строки равному номеру вставляемой из репликации записи.

Можно чуть подробне, особенно в районе "номера вставляемой из репликации записи".
ASCRUS
Хотя лично считаю, что пример притянут за уши и я бы на самом деле после отпуска машины со склада блокировал флагом документ на складе, чтобы его изменить мог только офис,

Ну блокировать - это хорошо. Просто в оригинале это не совсем склад - это два независимых подразделения с единой бухгалтерией на територии первого, и если во втором таким образом "подвиснут" документы, то это будет совсем не хорошо. Так что пришлось делать самим такую "подокументную" передачу данных через e-mail (связь была через GPRS модем). Правда дело было на MS SQL 2000.
Кстати, почему я путаю бизнес-логику и реализацию? Я бы процедуру разрешения конфликта отнес к репликации. Хм... хотя это интересный вопрос...
26 янв 06, 10:19    [2288908]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
автор
Можно чуть подробне, особенно в районе "номера вставляемой из репликации записи".

Извиняюсь, что не точно выразился. Я имел ввиду, что в любом случае строка ТТН должна помимо синтетического ключа иметь естественный ключ (хоть порядковый номер в накладной, вбиваемый ручками) и именно по этому ключу можно было бы отследить, что пришла запись с IsLocal = 0 и на нее уже существует с таким же натуральным ключом запись с IsLocal = 1, т.е. как временно введенная и ожидающая своего замещения с удаленного узла. Так или иначе мне кажется для конкретной задачи можно найти множества вариантов решений и выбрать из них наиболее оптимальный и лучший. Ну а кол-во таких решений определяется (ограничивается) как раз рамками функциональности сервера, на котором пишется проект. Здесь меня ASA вполне устраивает именно тем, что у этого сервера присутствует на борту широкий функционал, который позволяет мне действительно большой выбор решений и главное, легкий в освоении и использовании, с минимальным кол-вом ограничений и условий применения (ветвления), и сделанный в единой концепции языка WatomSQL, без каких либо прикруток, примочек или привязки к ОС (естественно кроме таких расширений, как поддержка MAPI, SNMP и т.д.).
26 янв 06, 10:59    [2289154]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
ASCRUS
Здесь меня ASA вполне устраивает именно тем, что у этого сервера присутствует на борту широкий функционал, который позволяет мне действительно большой выбор решений и главное, легкий в освоении и использовании, с минимальным кол-вом ограничений и условий применения (ветвления), и сделанный в единой концепции языка WatomSQL, без каких либо прикруток, примочек или привязки к ОС (естественно кроме таких расширений, как поддержка MAPI, SNMP и т.д.).

Ну не знаю. Мне просто больше нравится идея такой "подокументной" репликации в том случае, про который я говорил. Достаточно легко отследить все такие "нехорошие" случаи взаимного изменения данных, без всяких фокусов с такими дополнительными полями и т.д. У нас все скрипты (тригера, sp) генерятся по некоей метаинформации о базе в один скрипт, запускаеь его и репликация готова. :) Удобно.
26 янв 06, 14:25    [2290477]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Локшин Марк
ASCRUS
Здесь меня ASA вполне устраивает именно тем, что у этого сервера присутствует на борту широкий функционал, который позволяет мне действительно большой выбор решений и главное, легкий в освоении и использовании, с минимальным кол-вом ограничений и условий применения (ветвления), и сделанный в единой концепции языка WatomSQL, без каких либо прикруток, примочек или привязки к ОС (естественно кроме таких расширений, как поддержка MAPI, SNMP и т.д.).

Ну не знаю. Мне просто больше нравится идея такой "подокументной" репликации в том случае, про который я говорил. Достаточно легко отследить все такие "нехорошие" случаи взаимного изменения данных, без всяких фокусов с такими дополнительными полями и т.д. У нас все скрипты (тригера, sp) генерятся по некоей метаинформации о базе в один скрипт, запускаеь его и репликация готова. :) Удобно.

Ну тут кому как удобно и кто на чем готовит :) Я просто стараюсь всеми силами избегать велосипедов и пользоваться штатным функционалом. До перехода на ASA это не удавалось в полном обьеме, сейчас тьфу тьфу, куча проектов различных направлений и сложности, а ничего прикручивать не пришлось.
26 янв 06, 14:40    [2290541]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600


"ASCRUS" <nospam@sql.ru> сообщил/сообщила в новостях следующее:
news:2290541@sql.ru...
> Ну тут кому как удобно и кто на чем готовит :) Я просто стараюсь
всеми силами избегать велосипедов и пользоваться штатным функционалом. До
перехода на ASA это не удавалось в полном обьеме, сейчас тьфу тьфу, куча
проектов различных направлений и сложности, а ничего прикручивать не
пришлось.

Чисто практический вопрос. Как я понимаю в ASA можно настроить фильтр,
определяющий какие данные попадут под репликацию. А можно отфильтровать
удалённые записи по их содеожимому?

Posted via ActualForum NNTP Server 1.3

26 янв 06, 15:03    [2290669]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

protector пишет:
> Чисто практический вопрос. Как я понимаю в ASA можно настроить фильтр,
> определяющий какие данные попадут под репликацию. А можно отфильтровать
> удалённые записи по их содеожимому?

Разумеется. Публикация - это набор таблиц или частей таблиц. Часть
таблицы - это подмножество ее колонок и записей. Первое определяется
перечислением полей, второе - обычным условием WHERE

Posted via ActualForum NNTP Server 1.3

26 янв 06, 15:22    [2290763]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600


"Александр Гoлдун" <nospam@sql.ru> сообщил/сообщила в новостях следующее:
news:2290763@sql.ru...
>
> protector пишет:
> > Чисто практический вопрос. Как я понимаю в ASA можно настроить
фильтр,
> > определяющий какие данные попадут под репликацию. А можно
отфильтровать
> > удалённые записи по их содеожимому?
>
> Разумеется. Публикация - это набор таблиц или частей таблиц. Часть
> таблицы - это подмножество ее колонок и записей. Первое определяется
> перечислением полей, второе - обычным условием WHERE

Значит содержимое удалённыз записей сохраняется, раз на них можно наложить
условие WHERE?

Posted via ActualForum NNTP Server 1.3

26 янв 06, 15:29    [2290780]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Так и есть - через WHERE можно определить фильтр, под который будут попадать в репликацию записи (как раз мой пример с IsLocal). Перечислением полей можно указать, какие поля будут реплицироваться. А через указание поля или выражения кода подписчика можно регулировать направление движение информации по удаленным узлам (что как раз наглядно демонстрирует вот этот топик).
26 янв 06, 16:06    [2290954]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Александр Гoлдун
Member

Откуда:
Сообщений: 2290

protector пишет:

> Значит содержимое удалённыз записей сохраняется, раз на них можно наложить
> условие WHERE?

Э.... А что понималось под удаленными записями? Те, которые в удаленной
БД или те, которым сделали DELETE? :)

Posted via ActualForum NNTP Server 1.3

26 янв 06, 16:09    [2290976]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600


"ASCRUS" <nospam@sql.ru> сообщил/сообщила в новостях следующее:
news:2290954@sql.ru...
> Так и есть - через WHERE можно определить фильтр, под который будут
попадать в репликацию записи (как раз мой пример с IsLocal). Перечислением
полей можно указать, какие поля будут реплицироваться. А через указание поля
или выражения кода подписчика можно регулировать направление движение
информации по удаленным узлам (что как раз наглядно демонстрирует вот этот
топик).

Т.е. как я понимаю в публикации под условие Where попадают как уже удалённые
так и не удалённые записи. А состояние записи (удалена не удалена) можно
проверить?

Posted via ActualForum NNTP Server 1.3

26 янв 06, 16:12    [2290986]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
protector
Member

Откуда: Иваново, Россия
Сообщений: 600


"Александр Гoлдун" <nospam@sql.ru> сообщил/сообщила в новостях следующее:
news:2290976@sql.ru...
>
> protector пишет:
>
> > Значит содержимое удалённыз записей сохраняется, раз на них можно
наложить
> > условие WHERE?
>
> Э.... А что понималось под удаленными записями? Те, которые в
удаленной
> БД или те, которым сделали DELETE? :)

Те, которым сделали DELETE и которые должны попасть в публикацию.

Posted via ActualForum NNTP Server 1.3

26 янв 06, 16:13    [2290993]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
protector
Т.е. как я понимаю в публикации под условие Where попадают как уже удалённые
так и не удалённые записи. А состояние записи (удалена не удалена) можно
проверить?

Во первых когда на удаленной или консолидированной БД применяются изменения, то в срабатываемых триггерах можно спокойно видеть, кто их вызывает - пользовательская сессия или же репликация. Во вторых как я уже говорил, все что пойдет по репликации фиксируется в логе, причем фиксируется на момент произведения DML операции. Соотвествующе это означает, что мы на публикацию таблицы можем нацепить выражение/запрос в WHERE и в SUBSCRIBE BY (возврат кода подписчика для определения видимости информации). Таким образом, отвечая на Ваш вопрос, пишем в WHERE для публицируемой таблицы:
(Field <> 1 OR NOT UPDATING) AND (Field <> 2 OR NOT DELETING)
Здесь я отсекаю по репликации изменяемые записи, если поле Field равно 1 и удаляемые записи, если Field равняется 2. INSERTINT/UPDATING/DELETING - это ключевые слова WatcomSQL, позволяющие определить, какая операция производится на текущий момент, разрешенные к использованию в триггерах и всех процедур, функций и операторов, попадающих в внутрь области видимости триггера. Таким же образом я могу в WHERE репликации поставить свою функцию и вызывать ее с параметрами, передавая к примеру поля реплицируемой таблицы. В общем тут насколько хватает фантазии
26 янв 06, 18:10    [2291678]     Ответить | Цитировать Сообщить модератору
 Re: Проведите "ликбез" по распределенным базам данных.  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Гм. Горячие финские репликаторы.
На мой взгляд, который кажется совпадает с тем, что я читал.

Распределенной базой можно назвать совокупность несвязаных между собой баз, к таблицам которых можно произвести запрос в единой транзакции.
При чем тут спор о репликации?
Репликация это как раз нераспределенная база. Репликации в корне противоречат требованиям к РСУБД - в частности первому правилу Кодда. Потому что, при репликации любое значения нужно искать не только по столбцу и ключу, но и по имени сервера.
26 янв 06, 23:41    [2292594]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить