Re: репликация и что, что я никак не пойму
"Nikolay Trifonov" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > Теперь то, что у меня не укладывается в голове: КАК ДОБАВИТЬ В ЭТУ СХЕМУ > ТРЕТЬЮ ТОЧКУ СИНХРОНИЗАЦИИ ? Растолкуйте непонятливому, плз. А что такое третья точка?
Re: репликация и что, что я никак не пойму
> INSERT INTO CHANGES2(TABLEKEY,TABLENAME,OP,LOC_ID) > SELECT бла-бла-бла > FROM REPL_TABLES2 WHERE TABLENAME=DOCUMENTS; [большие, круглые глаза] > конектимся к базе через sysdba, апдейтим DOCUMENTS, данные об этом попадают > в changes, на этом этапе все ок. > > Реплицируем данные: коннектимся как REPL2 и в DOCUMENTS делаем изменения. > Соответственно в триггер они не попадают. > Теперь то, что у меня не укладывается в голове: КАК ДОБАВИТЬ В ЭТУ СХЕМУ > ТРЕТЬЮ ТОЧКУ СИНХРОНИЗАЦИИ ? Растолкуйте непонятливому, плз. Я так понял первые две точки синхронизации - это тоже широко известные понятия ? Коваленко Дмитрий. PS. Ночью надо спать, а не охинеей заниматься :)
Re: репликация и что, что я никак не пойму
Nikolay Trifonov wrote: Реплицируем данные: коннектимся как REPL2 и в DOCUMENTS делаем изменения. Соответственно в триггер они не попадают. Теперь то, что у меня не укладывается в голове: КАК ДОБАВИТЬ В ЭТУ СХЕМУ ТРЕТЬЮ ТОЧКУ СИНХРОНИЗАЦИИ ? Растолкуйте непонятливому, плз. Если мой ТЛ правильно подсказывает, то тебе нужно в лог вставлять по одной записи на каждую точку (target) синхронизации, и указывать в ней не только ЧТО, но и КОМУ. PS. Поищи описание птицевого репликатора на Phoenix-е, там 2 статьи: Fundamentals и Internals
Re: репликация и что, что я никак не пойму
> имеются в виду базы данных > > > PS. Ночью надо спать, а не охинеей заниматься :) > > Что делать если сроки... Понятно. На скорую руку - предлагаю сразу "убить себя ап стену" Вечером попытаюсь вникнуть в твою проблему. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
Nikolay Trifonov wrote: дык это понятно, в голове не укладывается другое: если мы сделали синхронизацию под учетной записью REPL2, то как сделать чтобы данные попали в Changes для синхронизации с третьей, четвертой и т.д. базами. Немного в голове это не укладывается, а английские доки еще более запутывают. Буду благодарен если кто уже подобное делал и обьяснит на пальцах. Эээ, у тебя двунаправленная что ли? Навскидку приходит такой вариант: делаешь ХП, через которую и вставляешь записи при репликации. На ее вход, наряду с данными, подаешь код базы - источника (в принципе, можно такое поле и в таблицу добавить, тогда ХП не понадобится). Ну и вставляешь в лог для всех кроме источника.
Re: репликация и что, что я никак не пойму
Я тут писал, писал. Потому стер. Вопрос - у тебя для каждой базы выделен свой диапазон значений генераторов? Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
> > Вопрос - у тебя для каждой базы выделен > > свой диапазон значений генераторов? > > > > естественно свой Спасибо. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
Nikolay Trifonov пишет: Если данные импортируются из филиала (логин REPL2), то данные в CHANGES не попадут, так как установлена проверка IF( USER <> 'REPL2' ) THEN. И вот в > эту схему надо как-то вписать что данные из второго филиала (REPL2) должны получить третий (я так понимаю надо делать > REPL3?) и четвертый. (надо REPL4 ?), а данные из третьего во второй и четвертый, из четвертого во второй и третий. И как раз работу с этими REPL2, REPL3 и REPL4 надо > вдолбить в мою голову. Можно совсем просто: В центре всегда формируется файл для всех. В данных указывается кто последний их изменил. А в филиале свои изменения игнорируются. Это создаёт некоторый излишек в передаваемых данных, но зато всем всегда отдаются одинаковые данные - значит не может быть путаницы. Ну и кроме того разгружается логика сервера. Если объем таки критичен, то можно сделать отдельную раздавалку фильтр - на вход подаётся единый файл и номер филиала - на выходе отфильтрованный файл для конкретногшо филиала.
Re: репликация и что, что я никак не пойму
И вот в эту схему надо как-то вписать что данные из второго филиала (REPL2) должны получить третий (я так понимаю надо делать REPL3?) и четвертый.(надо REPL4 ?), а данные из третьего во второй и четвертый, из четвертого во второй и третий. И как раз работу с этими REPL2, REPL3 и REPL4 надо вдолбить в мою голову. А нельзя ли проще поступить: Из филиала 1 пришел пакет с репликацией. Он загрузился в базу и этот же пакет отправился в филиалы 2,3,4 ...? With b/r. Gleb.
Re: репликация и что, что я никак не пойму
Tonal wrote: Можно совсем просто: В центре всегда формируется файл для всех. В данных указывается кто последний их изменил. А в филиале свои изменения игнорируются. Ну, тут получается 2 постулата: а) в филиале данные от REPL в лог изменений не попадают в принципе б) в центре обязательно помечается, ОТКУДА пришли данные (REPL уже не катит) и в лог пишутся данные для всех (метка "куда") кроме базы-источника.
Re: репликация и что, что я никак не пойму
Вырва Валерий Евгеньевич wrote: А почему бы не вставлять информацию о том от куда пришло обнавление? Я уж скока лет бубню, что самый естественный способ для реплицируемых таблиц - двухсегментный PK (Base_ID, Record_ID). Группировки-фильтрации и прочая в отчётах всяких потом делаются тривиально, не говоря уж о самой репликации. Но широкие массы продолжают упорно дробить диапазоны ключей и плодить гуиды с целью самозабвенно с ними впоследствии бороться... -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> > А почему бы не вставлять информацию о том от куда пришло обнавление? > >Я уж скока лет бубню, что самый естественный способ для реплицируемых > таблиц - двухсегментный PK (Base_ID, Record_ID). Мда. А по мне так и просто Record_ID достаточно. Естественней некуда :))) Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
> > Из филиала 1 пришел пакет с репликацией. Он загрузился в базу и этот же > > пакет отправился в филиалы 2,3,4 ...? > > В пакете содержится один источник назначения. Это первые 3 цифры имени файла > пакета. > Надо как-то загрузить данные в базу, похоже надо делать похожий триггер с > REPL3 и еще один с REPL4, завтра проекспериментирую И что, даже никаких мыслей о том, что менять конструкцию базы при появлении нового REPL_xxx - это не нормально, не появляется ? Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Мда. А по мне так и просто Record_ID > достаточно. Естественней некуда :))) ты про таблицы соответствия global_id <-> local_id забыл :-)
Re: репликация и что, что я никак не пойму
On Thu, 09 Nov 2006 22:01:15 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote: >>Я уж скока лет бубню, что самый естественный способ для реплицируемых >> таблиц - двухсегментный PK (Base_ID, Record_ID). > > Мда. А по мне так и просто Record_ID > достаточно. Естественней некуда :))) +1. В PK незачем пихать ID базы, лишний мусор в индексе. В рамках базы смысловой нагрузки не несёт. Этот ID нужен только для репликации :) -- Сергей Смирнов.
Re: репликация и что, что я никак не пойму
On Thu, 09 Nov 2006 22:52:45 +0300, Nikolay Trifonov <[EMAIL PROTECTED]> wrote: > Ты не прав (ИМХО), так как сложность почти всех запросов увеличивается и > намного Тебе это только кажется, пока сам не попробуешь ;) Такое разделение нужно, но вот в PK действительно не стоит запихивать BaseID. Но быть оно должно, даже если база у вас одна. -- Сергей Смирнов.
Re: репликация и что, что я никак не пойму
"Nikolay Trifonov" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > Ты не прав (ИМХО), так как сложность почти всех запросов увеличивается и > намного > Сложность запросов снижается. Репликация (синхронизация) значительно упрощается. Зато появляется информация для группировки. Проверено на: Центральная (главная) база - 1 шт. База в розничном подразделении - 18 шт. База в отделении (объединение нескольких розничных подразделений) - 5 шт. -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: репликация и что, что я никак не пойму
> > Мда. А по мне так и просто Record_ID > > достаточно. Естественней некуда :))) > > ты про таблицы соответствия global_id <-> local_id забыл :-) Ага, только не забыл, а закрысил :) Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
> > Ты не прав (ИМХО), так как сложность почти всех запросов увеличивается и > > намного > > Сложность запросов снижается. > Репликация (синхронизация) значительно упрощается. > Зато появляется информация для группировки. > Проверено на: <зеваю> - Репликация слиянием? - Как насчет маштабирования, например, числа уровней системы? Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > - Репликация слиянием? Ни в коем случае. Каждому только, то что его касается. Репликация синхронизацией справочников (всем все), обменом: документы (кому какие - ID базы), журналы продаж (кому какие - ID, Parent_ID базы), текущие остатки (кому какие - ID, Parent_ID базы), категории ассортимента (кому какие - ID, Parent_ID базы), акцепты/не акцепты позиций накладных (кому какие - ID, Parent_ID базы), графики работы, смен (кому какие - ID, Parent_ID базы), возвраты на центр. склад (кому какие - ID, Parent_ID базы), переброски между подразделениями розничными точками (кому какие - ID, Parent_ID базы), и т.д. Много чего. > - Как насчет масштабирования, например, > числа уровней системы? Уровни системы увеличиваются непросто. Потребуется 2-3 дня. Новая база, новое розничное подразделение или отделение - объединение розничных подразделений создаются за 5-10 мин. простым суппортером. -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: Мда. А по мне так и просто Record_ID достаточно. Естественней некуда :))) ты про таблицы соответствия global_id <-> local_id забыл :-) Ага, только не забыл, а закрысил :) Да лана тебе. Двухсегментный PK - это, по сути, завуалированный 1:n с табличкой-справочником баз. А это, в свою очередь, частный случай m:n - то бишь таблицы соответствия. Ясень пень, что наиболее общее решение накрывает всё, но опять же ясен пень, не все частные случаи оптимально. Для данных, информация о принадлежности которых к базам имеет смысловое значение, используемое в деятельности центра (документы, скажем) двухсегментный PK эффективнее. Для централизованно ведущихся справочников (номенклатура, скажем) вообще никаких ухищрений не нужно, они в сателлитах ридонли. А вот данные, не отражающие деятельность сателлитов, а констатирующие объективную реальность, данную им на местах в ощущениях, которая (реальность) может промеж них пересекаться (справочник организаций-партнёров, скажем) - уже только таблица соответствия. -- Regards. Ded.
Re: репликация и что, что я никак не пойму
On Fri, 10 Nov 2006 10:57:52 +0300, Oleg LOA wrote: > ты про таблицы соответствия global_id <-> local_id забыл :-) Может, ты хотел сказать "base1.local_id != base2.local_id" ? Потому как local_id - это вроде часть от global_id. -- Сергей Смирнов.
Re: репликация и что, что я никак не пойму
> Для данных, информация о принадлежности которых к базам имеет смысловое > значение, используемое в деятельности центра (документы, скажем) > двухсегментный PK эффективнее. Убей себя ап стену. Если тебе нужно знать какому филиалу принадлежит документ, то это нужно оформить явно, в виде отдельных колонок (атрибутов). Например, как часть номера документа. Бугагагагага. ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!! Хочешь уникальность - повесь UNIQUE. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
ArtGal wrote: Ни в коем случае. Каждому только, то что его касается. Его зевки - от специфичной предметной области (учёт недвижимости). Он обслуживает фактически не деятельность (процесс), а регистрацию статики конечного автомата и переходов его из одного состояния в другое. Ну а каждому из нас свойственно собственное мироощущение, основанное на собственном опыте контактов с мирозданием, возводить в ранг вселенского абсолюта :) Это не проходит, но нивелируется с возрастом, просто по причине расширения сферы сих контактов и опыта... -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> > - Репликация слиянием? > > Ни в коем случае. Каждому только, то что его касается. > > Уровни системы увеличиваются непросто. Потребуется 2-3 дня. Меня вот что во всех этих схемах напрягает - так это их хрупкость и ограниченность. 1. Захочешь слияние - хрен тебе. 2. Захочешь завести новую базу или новуй тип данных - не дай бог облажаться с разнесением диапазонов. 3. Захочешь децентрализованную систему - см. пункт номер 1 Коваленко Дмитрий. PS. Я молчу про репликацию "SQL запросов", а не самих данных.
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: Убей себя ап стену. Не, это не мой способ. Лобные кости слишком крепкие. Я на потенциально возможный случай крайней необходимости другой способ придумал, поприятнее. Если тебе нужно знать какому филиалу принадлежит документ, то это нужно оформить явно, в виде отдельных колонок (атрибутов). Например, как часть номера документа. А что есть сегмент PK как не отдельная колонка? И часть номера (внутреннего)? ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!! Есть такое слово - денормализация. Бывает и полезной и вредной. В данном случае позволяет совмещать два напитка в одной посуде без ущерба для вкусовых качеств и того и другого. -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> > Ни в коем случае. Каждому только, то что его касается. > > Его зевки - от специфичной предметной области (учёт недвижимости). > Он обслуживает фактически не деятельность (процесс), а регистрацию > статики конечного автомата и переходов его из одного состояния в другое. > Ну а каждому из нас свойственно собственное мироощущение, основанное на > собственном опыте контактов с мирозданием, возводить в ранг вселенского > абсолюта :) Это не проходит, но нивелируется с возрастом, просто по > причине расширения сферы сих контактов и опыта... Ну ты еще скажи, что я и провайдер делал с учетом специфики недвижимости :)) Коваленко Дмитрий. PS. Мой репликатор можно без проблем запрограммировать под "каждому свое". Но мне это было не интересно :))) PSS. Хотя некоторые вещи у нас именно так и реплицируются. Так запрограммирована логика для этих вещей.
Re: репликация и что, что я никак не пойму
"""Ded писал(а): """ > Kovalenko Dmitry wrote: > > > Убей себя ап стену. > >Не, это не мой способ. Лобные кости слишком крепкие. Я на > потенциально возможный случай крайней необходимости другой способ > придумал, поприятнее. :BEER: Коваленко Дмитрий. PS. Блин, я так хотел встретить тебя на московской тусовке :(
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > Меня вот что во всех этих схемах > напрягает - так это их хрупкость и > ограниченность. > > 1. Захочешь слияние - хрен тебе. При наличии ID записи, ID базы, Parent_ID базы это делается просто слиянием. > 2. Захочешь завести новую базу или > новуй тип данных - не дай бог > облажаться с разнесением диапазонов. Какое разнесение диапазонов. В шахту разнесение диапазонов. А шахту засыпать. ID записи, ID базы, Parent_ID базы - рулез. > 3. Захочешь децентрализованную систему > - см. пункт номер 1 Смотри ответна п.1. -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи). ЗЫ. А провайдер действительно хорош. 1С (по бедности своей) лазит в нашу базу за инфой через твоего провайдера очень даже хорошо.
Re: репликация и что, что я никак не пойму
Hello, Kovalenko Dmitry said the following on 10.11.2006 11:20: > - Репликация слиянием? > - Как насчет маштабирования, например, числа уровней системы? Ты бы статью написал, что ли... ;-) -- Oleg
Re: репликация и что, что я никак не пойму
> > 1. Захочешь слияние - хрен тебе. > > При наличии ID записи, ID базы, Parent_ID базы > это делается просто слиянием. А что такое Parent_ID базы ? Это ID записи или ID базы ? Коваленко Дмитрий. PS. Thanks :)
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: PS. Блин, я так хотел встретить тебя на московской тусовке :( Да я бы тоже с удовольствием, но у меня долгожданный отпуск висел на волоске. Как всегда вовремя очередное "хватай мешки, вокзал уходит" случилось, недели три без выходных по 14 часов пахал. -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> > - Репликация слиянием? > > - Как насчет маштабирования, например, числа уровней системы? > > Ты бы статью написал, что ли... ;-) Про репликацию? Сгинь, проклятый. Я про первичные ключи в свете репликации пока писал, чуть не опух :) http://www.rsdn.ru/File/84/primary_keys_and_replication.zip Коваленко Дмитрий. PS. Так и не сказал тогда DED'у спасибо. Вот такой я мерзавец :-)
Re: репликация и что, что я никак не пойму
> > ты про таблицы соответствия global_id <-> local_id забыл :-) > > Может, ты хотел сказать "base1.local_id != base2.local_id" ? Не, он имел в виду мою таблицу, в которой для каждого local_id указан внешний идентификатор Внешний (ну или глобальный) идентификатор - это BaseID+LocalID > Потому как local_id - это вроде часть от global_id. Так точно. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
"Oleg Deribas" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Hello, > > Kovalenko Dmitry said the following on 10.11.2006 11:20: > >> - Репликация слиянием? >> - Как насчет маштабирования, например, числа уровней системы? > > Ты бы статью написал, что ли... ;-) Статья давно написана. Дима ты её до публикуемого состояния доводил?
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: PS. Так и не сказал тогда DED'у спасибо. Вот такой я мерзавец :-) Да я тебе тогда не особо и помог. У меня осталось впечатление, что мы с тобой тогда малость на разных языках говорили, как за нами частенько водится :) -- Regards. Ded.
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ > КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!! 1. (С) не твой :-) 2. ПОВЕСИТЬ В РАМКУ НА СТЕНКУ
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > А что такое Parent_ID базы ? Прикалываешься? Parent_ID это ID базы отделния, которое является объединением нескольких розничных подразделений. Справочник аптек и отделений - есть список баз. ID Parent_ID Name 0 0 Предприятие (база 0) 1 0 Отделение 1 (база 1) 2 1 Аптека 11 (база 2) 3 1 Аптека 12 (база 3) ,, 14 0 Отделение 3 (база 14) 15 14Аптека 31 (база 15) 16 14Аптека 12 (база 16) ,, CREATE TABLE DRUGSTORE ( ID INTEGER NOT NULL, PARENT_ID INTEGER DEFAULT -199, . NAMEVARCHAR(63) NOT NULL COLLATE PXW_CYRL, KINDINTEGER DEFAULT 10 NOT NULL, .. ); ALTER TABLE DRUGSTORE ADD CONSTRAINT DRUGSTORE_PK PRIMARY KEY (ID); ALTER TABLE DRUGSTORE ADD CONSTRAINT DRUGSTORE_DRUGSTORE FOREIGN KEY (PARENT_ID) REFERENCES DRUGSTORE (ID) ON UPDATE CASCADE; ALTER TABLE DRUGSTORE ADD CONSTRAINT DRUGSTORE_DRUGSTORE_KIND FOREIGN KEY (KIND) REFERENCES DRUGSTORE_KIND (ID) ON UPDATE CASCADE; -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ > КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!! > А если случайно получилось. Завести еще одно поле, но уже без всякого смысла? 8-) -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: репликация и что, что я никак не пойму
> > А что такое Parent_ID базы ? > Прикалываешься? Да нет, вроде. > Parent_ID это ID базы отделния, которое является объединением > нескольких розничных подразделений. > Справочник аптек и отделений - есть список баз. > ID Parent_ID Name > 0 0 Предприятие (база 0) > 1 0 Отделение 1 (база 1) > 2 1 Аптека 11 (база 2) > CREATE TABLE DRUGSTORE ( > ALTER TABLE DRUGSTORE ADD CONSTRAINT DRUGSTORE_DRUGSTORE FOREIGN KEY > (PARENT_ID) REFERENCES DRUGSTORE (ID) ON UPDATE CASCADE; Не, это у тебя иерархия баз. Я, когда говорил про репликацию слиянием, имел в виду ситуацию независимого создания идентичных объектов в филиальных базах, которые (после репликации) в центральной базе будут представлены ровно одним объектом (хорошо, одной записью). То есть - создаем Иванова там и там. Потом реплицируем сюда и хотим увидеть здесь только одного Иванова, а не двух ... Прости LOA, я не специально :) Если у тебя для каждой записи привязывается BaseID, то возникает вопрос - какой BaseID выбрать. Или я не въехал в идею? Коваленко Дмитрий. PS. Модификация первичного ключа - ЗЛО.
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: хотим увидеть здесь только одного Иванова, а не двух ... Прости LOA, я не специально :) Ващета имхо если б их было два, FB было бы только лучче :-D -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> > Ты бы статью написал, что ли... ;-) > > Статья давно написана. Дима ты её до публикуемого состояния доводил? Дык это, того. Если чего не так - доводите и публикуйте. Главное соблюдайте основные правила русского языка - "в жо.у" пишется раздельно, а "нах.р" слитно. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
WildSery wrote: Этот ID нужен только для репликации :) В центральной базе - вполне нужен
Re: репликация и что, что я никак не пойму
ArtGal wrote: А если случайно получилось. Завести еще одно поле, но уже без всякого смысла? Разумеется! и заполнять случайными числами
Re: репликация и что, что я никак не пойму
"ArtGal" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > "Kovalenko Dmitry" <[EMAIL PROTECTED]> > сообщил/сообщила в новостях следующее: > news:1163152933.069029.273230-kgokzNqkTZsvLoKJ9UdeTWB/[EMAIL PROTECTED] >> >> ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ >> КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!! >> > > > А если случайно получилось. > Завести еще одно поле, но уже без всякого смысла? Тоды это естественный ключ :-)
Re: репликация и что, что я никак не пойму
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Kovalenko Dmitry wrote: > >> хотим увидеть >> здесь только одного Иванова, а не двух >> ... Прости LOA, я не специально :) > >Ващета имхо если б их было два, FB было бы только лучче :-D Ну вотопять в попугаях сосчитали :-):-):-)
Re: репликация и что, что я никак не пойму
То есть - создаем Иванова там и там. Потом реплицируем сюда и хотим увидеть здесь только одного Иванова, а не двух ... Прости LOA, я не специально :) А вот бывает у тебя такие ситуации: Тут ввели Иванова, и там ввели Иванова, но пока еще непонятно один ли это Иванов или два. Произошла репликация. Cколько у тебя окажется Ивановых? With b/r. Gleb.
Re: репликация и что, что я никак не пойму
Мадорский Г.В. wrote: А вот бывает у тебя такие ситуации: Тут ввели Иванова, и там ввели Иванова, но пока еще непонятно один ли это Иванов или два. Произошла репликация. Cколько у тебя окажется Ивановых? Репликация такого рода данных, требующих именно таблицы соответствия, невозможна на чиста автоматном уровне. Так или иначе в разруливании некоторых конфликтов должен принимать участие ЛПР. Если забыл курс АСУ - это Лицо, Принимающее Решение :) -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> > То есть - создаем Иванова там и там. > > Потом реплицируем сюда и хотим увидеть > > здесь только одного Иванова, а не двух > > ... Прости LOA, я не специально :) > > > > А вот бывает у тебя такие ситуации: > Тут ввели Иванова, и там ввели Иванова, но пока еще непонятно один ли это > Иванов или два. Произошла репликация. Cколько у тебя окажется Ивановых? Если не понятно - то будет два. Даже если потом станет ясно - все равно будет два :( Одного нужно будет грохнуть. Мда. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
Nikolay Trifonov пишет: > Сорри, но начну новый пост, ОЕ заглючил. > > один вопрос у меня в голове не укладывается: есть таблица CHANGES, в которой > для репликации записываются в какой строчке что изменилось триггером: > Сразу извиняюсь за размер поста, но коротко тут не скажешь... вопрос репликации достаточно сложный сам по себе, да еще индивидуальные особенности БД + конторы накладывают ограничения. Поделюсь своим решением, которое IMHO не панацея, но работает: Имеем: а) 32 филиала (автоматизированная точка розничной продажи). Кратко назовем "ПОФ" б) 1 центральный офис для автоматизированных филиалов. Кратко назовем "ПОЦО" в) система которая связана с закупкой товара у поставщиков (прием заявок от филиалов, их обработка, отправка поставщикам). "Первичные" справочники, от которых все "пляшут" - именно тут. Кратко назовем "ПОГИД" Системы ПОФ и ПОЦО написаны мною, соответственно могу делать с ними все, что хочу. Система ПОГИД работает в конторе давно, исходников нет, так что модификации допускаются на уровне БД. Нужна была система с "общими синхронизированными" справочниками и "чтобы в ПОЦО были все документы из ПОФ". В ПОФ ДОПУСКАЕТСЯ заведение новых записей в справочники! Долго думал, в итоге получилась такая конфигурация ПО (только то, что касается репликации): 1) ПОФ и ПОЦО используют один и тот же исполняемый файл (что значительно облегчило мою работу) и отличаются нюансами "реализации" БД (несколько иной набор "служебных" таблиц, триггеров и ХП). а) Реализован встроенный механизм импорта справочников из ПОГИД, в котором готовятся 9 файлов со справочниками: товары, контрагенты и т.д. В справочниках ПОФ и ПОЦО используется простой PK с заполнением по генератору, во всех справочниках есть поле "ссылка_на_погид" в котором должно храниться значение PK из ПОГИД. Когда импортируется запись в справочник ПОФ или ПОЦО - проверяется наличие такого значения в "ссылка_на_погид", если оно есть - то update, если нет - то insert. Когда запись заноситься юзером, то поле "ссылка_на_погид" is null. Когда формируется пакет данных из ПОФ для ПОЦО то из справочников ПОФ выбираются записи у которых "ссылка_на_погид" is null, которые потом импортируются (через "таблицу перекодировок": "код филиала"-"PK_в_филиале" - "PK_в_ЦО"...) в БД ПОЦО. Это упрощенно, так как на самом деле проверяется наличие "такой" записи, если она есть - то импорта не происходит - проставляется код существующей записи. В ПОЦО работает еще одна программа, которая смотрит БД ПОЦО на наличие is null и позволяет указать код соответствующего PK из ПОГИД. В результате в филиал отправляется файл, который содержит информацию "код филиала"-"PK_в_филиале" - "PK_в_ПОГИД" - "таблица", когда он импортируется, то в соответствующей записи поле "ссылка_на_погид" становится равна "PK_в_ПОГИД" и она перестанет передаваться в ПОЦО. При следующем импорте справочников в ПОФ - данная строка будет обновлена полностью. Плюс в БД ПОФ реализован механизм "перехода на PK с наибольшим значением для общего "ссылка_на_погид"". Допустим есть две строки в справочнике: pk - "ссылка_на_погид" 1100 2100 это не очень красиво, поэтому при проставлении значения в поле "ссылка_на_погид" проверяется наличие записей с таким же значением и с помощью триггера происходит перенос данных на новый код, например вот так: AS declare variable tmp_analog_id integer; begin if (new.parent_id is not null) then begin for select an.analog_id from analog an where an.parent_id = NEW.PARENT_ID and an.analog_id <> NEW.analog_id into :tmp_analog_id do begin update defectureitem di set di.analog_id = NEW.analog_id WHERE di.analog_id = :tmp_analog_id; update sprice sp set sp.analog_id = NEW.analog_id WHERE sp.analog_id = :tmp_analog_id; update goods gd set gd.analog_id = NEW.analog_id WHERE gd.analog_id = :tmp_analog_id; delete from analog an where an.analog_id = :tmp_analog_id; end end end /*конец триггера*/ в итоге имеем "красивые и синхронизированные" справочники, причем никто не ограничивает из заполнение в ПОФ. Для этого нужно: процедура импорта справочников из ПОГИД, выгрузка "заведенных" в ПОФ записей в ПОЦО, импорт в ПОФ ссылок из ПОЦО. б) теперь касаемо документов и связанных с ними таблиц. Все документы, которые влияют на товарный запас имеют набор триггеров, которые фиксируют в "таблицах состояния" необходимость передачи этого документа в ПОЦО. Например вот так: AS begin /*добавление документа в список синхронизируемых*/ UPDATE sync$move sm SET sm.time_send = null, sm.time_recv = null WHERE sm.pr_key = NEW.move_id; IF (row_count = 0) THEN BEGIN INSERT INTO sync$move (pr_key) VALUES(NEW.move_id); END end AS begin /*удаление документа из списка синхронизируемых*/ DELETE FROM sync$move sm WHERE sm.pr_key = OLD.move_id; /*добавление документа в список
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: То есть - создаем Иванова там и там. Одного нужно будет грохнуть. Мда. Олежка, ты там пригнись на всякий пожарный. -- Regards. Ded.
Re: репликация и что, что я никак не пойму
> разруливании некоторых конфликтов должен принимать участие ЛПР. Если > забыл курс АСУ - это Лицо, Принимающее Решение :) Не знал и забыл :) Меня в "школе" математикой шпинговали. Я её тоже всю напрочь, благополучно забыл. Точнее её вытеснили безумные мысли об объектной базе и компонентном программировании :))) Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
KD> Одного нужно будет грохнуть. Мда. ненадо грохать ниодного. Иванов то чем виноват? И так сметность большая. -- Кочмин Александр
Re: репликация и что, что я никак не пойму
> KD> Одного нужно будет грохнуть. Мда. > > ненадо грохать ниодного. Иванов то чем виноват? > И так сметность большая. Не, я против. Дублеры - ЗЛО. Со смертностью нужно бороться по другому - нехер в конфе часами висеть, займись действительно стоЯщим делом :))) Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry пишет: Дык это, того. Если чего не так - доводите и публикуйте. Главное соблюдайте основные правила русского языка Учтут! Я вот только удивлен, почему до сих пор никто не опубликовал?! Я к таким же выводам сам в своем корыте плыл мучительно долго. А прочитал бы раньше - нервов съэкономил бы немало. Сложил в закрома и раздал почитать всем знакомым. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: репликация и что, что я никак не пойму
On Fri, 10 Nov 2006 15:10:27 +0300, Ded <[EMAIL PROTECTED]> wrote: > Ващета имхо если б их было два, FB было бы только лучче :-D Только в случае, если их никто не слил репликацией в одного :) -- Сергей Смирнов.
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED] > > в виду ситуацию независимого создания > идентичных объектов в филиальных > базах, которые (после репликации) в > центральной базе будут представлены > ровно одним объектом (хорошо, одной > записью). Неее... У нас такое запрещено на уровне бизнес-процессов. Справочники ведутся только в базе 0 (центральный офис). Да и обмен между базами происходит только через центральную базу 0. > То есть - создаем Иванова там и там. > Потом реплицируем сюда и хотим увидеть > здесь только одного Иванова, а не двух > ... Прости LOA, я не специально :) Да уж. Два LOA - птицы толще 8-) А вообще предполагается, что Иванов рожденный в аптеке 1 и Иванов рожденный в аптеке 2 - разные Ивановы, т.к. мамы у них разные (папа может быть один и тот же - отделение). > Если у тебя для каждой записи > привязывается BaseID, то возникает вопрос > - какой BaseID выбрать. Разные BaseID, т.к. экземпляры сущностей созданные в разных ситуациях и по разным причинам - это различные экземпляры. Ну, по крайней мере, с нашей колокольни это так выглядит. Нет в мире совершенства, но работает и особых проблем пока нет. Конечно, разные задачи, разные процессы => разные решения. > PS. Модификация первичного ключа - ЗЛО. Оно конечно так, но иногда так хочется помодифицировать. Хотя бы чтобы список отсортировать. -- С уважением, Артур Галимов. ФК "ФармМедСервис" (Сочи).
Re: репликация и что, что я никак не пойму
On Fri, 10 Nov 2006 15:23:57 +0300, Konstantin R. Beliaev <[EMAIL PROTECTED]> wrote: > В центральной базе - вполне нужен Согласен. Но ответ не полный. В центральной базе у меня свои PK. И ID базы в него не входит. Это всего лишь поле дополнительное. Ну с индексом, как же без него. -- Сергей Смирнов.
Re: репликация и что, что я никак не пойму
> Ващета имхо если б их было два, FB было бы только лучче :-D Хм, вообще говоря, FB на пользу пойдет клонирование Еманова и Хорсуна ;) Ну или, по крайней мере, кормить их по-лучше что-ли, чтобы они стали ПО-БОЛЬШЕ :))) Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Со смертностью нужно бороться по > другому - нехер в конфе часами висеть, > займись действительно стоЯщим делом > :))) У вообще-то уже двое :-):-):-)
Re: репликация и что, что я никак не пойму
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Хм, вообще говоря, FB на пользу пойдет > клонирование Еманова и Хорсуна ;) > > Ну или, по крайней мере, кормить их > по-лучше что-ли, чтобы они стали > ПО-БОЛЬШЕ :))) Нафиг клонировать - достаточно денег и толкового менеджера проекта :-):-):-)
Re: репликация и что, что я никак не пойму
On Fri, 10 Nov 2006 17:30:10 +0300, Kovalenko Dmitry <[EMAIL PROTECTED]> wrote: > Хм, вообще говоря, FB на пользу пойдет > клонирование Еманова и Хорсуна ;) insert into FB_Developers (id, name) select gen_id(gen_id_develop, 1), name from FB_Developers where (name like 'Еманов' or name like 'Хорсун') and gen_id(gen_id_develop, 0)<=100; -- Сергей Смирнов.
Re: репликация и что, что я никак не пойму
Kovalenko Dmitry wrote: Не, я против. Дублеры - ЗЛО. Коваленко Дмитрий. Дык, всем известно что Дмитрий Коваленко и Коваленко Дмитрий - это совсем разные люди ;-)
Re: репликация и что, что я никак не пойму
> >> ПЕРВИЧНЫЙ КЛЮЧ НЕ ДОЛЖЕН НЕСТИ > >> КАКУЮ-ЛИБО СМЫСЛОВУЮ НАГРУЗКУ !!! > >> > > > > > > А если случайно получилось. > > Завести еще одно поле, но уже без всякого смысла? > > Тоды это естественный ключ :-) Отсюда вывод: естественный ключ не может быть первичным ключём. Однако!...
Re: репликация и что, что я никак не пойму
> Ну как в этот оутлуке увидеть емайл отправителя? [dima <та еще сАбака> lcpi.lipetsk.ru] Но лучше спрашивай здесь, на форуме. Коваленко Дмитрий.
Re: репликация и что, что я никак не пойму
Nikolay Trifonov пишет: Ну засинхронизировал ты ПОФ1 с ПОЦО, но потом эти же данные надо передать в ПОФ1 и ПОФ2, как это делаешь? у меня так: 1) филиалы передают друг другу только "электронные накладные" (чтобы товар было проще приходовать) 2) из филиала в ЦО и обратно передаются справочники (в конце концов, запись заведенная в одном филиале попадает во все филиалы, НО через выгрузку из ЦО) 3) все документы собираются в единой БД, находящейся в ЦО. Филиалы имеют ограниченный доступ к этой БД (типа посмотреть остатки по товару в других филиалах). Заведующие отделений (по 5 филиалов на каждого) имеют чуть более широкие полномочия - могут смотреть отчеты по подотчетным филиалам... Если Вам нужно иметь "полный набор" документов во ВСЕХ филиалах, то тут все зависит о того, имеет ли право филиал "менять" не свои документы: Если нет, я бы сделал так: 1) сформировал "общую" БД по всем филиалам 2) копию "общей" БД разместил в каждом филиале 3) при формировании пакетов на синхронизацию с "общей" БД - отправлял бы этот пакет во все филиалы и в ЦО. Этот пакет в каждом филиале загружается в копию "общей" БД (и не забывают про свой пакет). В итоге имеем в каждом филиале 2 БД: 1 - только свои документы (делаем что хочем в этой БД), 2 - все документы (и свои тоже) (только на чтение) Станислав
Re: репликация и что, что я никак не пойму
"Dmitry Voroshin" wrote in message news:[EMAIL PROTECTED] > Отсюда вывод: естественный ключ не может быть первичным ключём. Однако!... Т.к. добавление искуственного ключа не ухудшает НФ
Re: репликация и что, что я никак не пойму
Oleg LOA wrote: "Dmitry Voroshin" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Отсюда вывод: естественный ключ не может быть первичным ключём. Однако!... Т.к. добавление искуственного ключа не ухудшает НФ Он полуестественный :-D Сегменты-то искусственные -- Regards. Ded.
Re: репликация и что, что я никак не пойму
"Evgeny Putilin" wrote in message news:[EMAIL PROTECTED] > Т.к. добавление искуственного ключа не ухудшает НФ >Какую именно? Наличие одновременно двух возможных ключей как раз одну из форм >нарушает. Уточни какую ;-)
Re: репликация и что, что я никак не пойму
rstas wrote: ... "ПОФ" ... "ПОЦО" ... "ПОГИД" > ... Вспоминается: "Нет такого предмета, который не мог бы стать еврейской фамилией" ;-) Дальше интересно, но первый абзац преодолел с трудом :-)
Re[2]: репликация и что, что я никак не пойму
Здравствуйте, Nikolay. Вы писали 7 ноября 2006 г., 23:22:38: > "Konstantin R. Beliaev" <[EMAIL PROTECTED]> wrote in > message news:[EMAIL PROTECTED] > Да, двухнаправленная. Но к счастью все базы удаленных точек синхронизируются > только через центральный офис. ХП не проходит, единственный вариант это > прользуясь таблицей CHANGES вытягиваем данные и подготавливаем SQL запросы > на вставку, обновлени, удаление. Эти запросы в текстовый файл, который > передаем и импортируем в базу приемник. Все это уже успешно отлажено, в > CHANGES есть поле loc_id, оно и указывает, в какую базу что вставляем. Я > никак не пойму, каким образом разрулить триггера. Т.е. при: > CREATE TRIGGER DOCUMENTS_REPL2 FOR DOCUMENTS > AFTER UPDATE AS > BEGIN > IF( USER <> 'REPL2' ) THEN > BEGIN > INSERT INTO CHANGES2(TABLEKEY,TABLENAME,OP,LOC_ID) > SELECT бла-бла-бла > FROM REPL_TABLES2 WHERE TABLENAME=DOCUMENTS; > END > END > работе данного триггера из таблицы REPL_TABLES2 берутся уже заданные > параметры LOC_ID. и > понятно, что если данные вводятся в офисе (логин SYSDBA) то они в changes > попадут для всех филиалов. Если данные импортируются из филиала (логин > REPL2), то данные в CHANGES не попадут, так как установлена проверка IF( > USER <> 'REPL2' ) THEN. И вот в эту схему надо как-то вписать что данные из > второго филиала (REPL2) должны получить третий (я так понимаю надо делать > REPL3?) и четвертый.(надо REPL4 ?), а данные из третьего во второй и > четвертый, из четвертого во второй и третий. И как раз работу с этими REPL2, > REPL3 и REPL4 надо вдолбить в мою голову. А почему бы не вставлять информацию о том от куда пришло обнавление? То есть пишем в таблицу информацию о том что изменение посадил "SYSDBA", и при подготовке к репликации для любого филиала знаем что эти данные нужно брать. Если данные сели от пользователя Второго филиала, то система будет знать что для репликации на 1, 3..15 нужно эти данные брать. Пользователей можно оформить в табличку из сажать их ID. -- С уважением, Вырва Валерий Евгеньевич Программист ТОО "СофтИнженер"
Re[2]: репликация и что, что я никак не пойму
> Мда. А по мне так и просто Record_ID > достаточно. Естественней некуда :))) А поподробнее? ;) _ С уважением, Юрий
