powered by simpleCommunicator - 2.0.53     © 2025 Programmizd 02
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / репликация, ПК,ФК
20 сообщений из 20, страница 1 из 1
репликация, ПК,ФК
    #39080605
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.

Никогда не задавался вопросами репликации. Вот сейчас появилась необходимость

есть две таблицы

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
CREATE TABLE TEST2015 (
    ID  INTEGER NOT NULL,
    FIRM_ID  INTEGER NOT NULL
);
ALTER TABLE TEST2015 ADD CONSTRAINT PK_TEST2015 PRIMARY KEY (ID, FIRM_ID);

CREATE TABLE TEST2015_SUB (
    ID    INTEGER NOT NULL,
    TEST2015_ID   INTEGER NOT NULL,
    FIRM_ID  INTEGER NOT NULL,
    ASD  SMALLINT
);

ALTER TABLE TEST2015_SUB ADD CONSTRAINT PK_TEST2015_SUB PRIMARY KEY (TEST2015_ID, FIRM_ID);
ALTER TABLE TEST2015_SUB ADD CONSTRAINT FK_TEST2015_SUB_1 FOREIGN KEY (TEST2015_ID, FIRM_ID) REFERENCES TEST2015 (ID, FIRM_ID);



ID в таблицах на генераторе. те по сути уникально.

По мне (хотя могу заблуждаться) репликацию типа клиент-центр-клиент тут можно сделать по TEST2015.ID+FIRM_ID и TEST2015_SUB.TEST2015_ID+FIRM_ID
И должна работать, тк FIRM_ID уникальна в пределах всех имеющихся баз. Центр раздает конфигурационный файл с указанием FIRM_ID. на клиенте добавить фирму нельзя.

и даже если в центре будут добавляться документы от имени-ИД центра и test2015.ID в центре пересечется с test2015.ID клиента, то все равно сработает ПК в TEST2015.

Вот только смущает избыточность в виде TEST2015_SUB.FIRM_ID. с таким пока не сталкивался. Вот по этой причине и смущает.

На сколько это соответствует практике?)

Спасибо
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080625
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swvсмущает избыточность в виде TEST2015_SUB.FIRM_ID
Зря.

SwvНа сколько это соответствует практике?)
Есть всего три способа распределённой генерации уникальных ключей:
1) Составной ключ;
2) Разнесение по диапазонам;
3) UUID.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080631
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЕсть всего три способа распределённой генерации уникальных
ключей:
И, собственно говоря, второй способ это денормализация (потеря первой НФ) первого способа.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080639
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

тут упрощенный пример. в test2015 пк получается из 4 полей.Соответственно в sub тянутся тоже 4 поля
В sub получается ФК из тех же 4 полей плюс ПК из 5 соответственно.

А вот на sub ссылаются еще 10 таблиц. А раз ПК у sub из 5 полей, то чтобы в этих 10 таблицах ФК создать, что опять таки в них придется тащить эти самые пять полей. ну и ПК у них уже вырастет до 6 полей.

Вот это вот и смущает
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080645
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SwvВот это вот и смущает
Не, это уже бред. Переходи на UUID-ы.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080650
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

те в предыдущем сообщении я описал все верно?)
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080653
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swvте в предыдущем сообщении я описал все верно?)
Не совсем, но для начала сойдёт. Допилишь по ходу возникновения проблем.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080662
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

проблем на предмет?
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080676
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Swvпроблем на предмет?
Доживёшь - увидишь.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080681
Swv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

имели ввиду репликацию?
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080714
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
SwvЗдравствуйте.

Никогда не задавался вопросами репликации. Вот сейчас появилась необходимость

есть две таблицы


Если не очень страшно, то можешь почитать как это было сделано в одном моём проекте (2004-2008 год). Вкратце - FIRM_ID не нужен. Использовалась таблица переназначений и репликатор с программируемой логикой. В документе написано только про таблицу переназначений :).
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080721
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Коваленко Дмитрийбыло сделано в одном моём проекте (2004-2008 год)
GUID-ы тогда уже изобрели вроде бы...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080738
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovКоваленко Дмитрийбыло сделано в одном моём проекте (2004-2008 год)
GUID-ы тогда уже изобрели вроде бы...


Да, и IBReplicator (2003 год) тоже уже был :)

---
Я там описал, почему гуиды не помогут.
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39080747
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Но таблицы соответствия это такой геморрой...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39081007
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Dimitry Sibiryakov!
You wrote on 20 октября 2015 г. 11:15:29:

Dimitry Sibiryakov> И, собственно говоря, второй способ это денормализация (потеря первой НФ) первого способа.
с этим можно поспорить.
но мне лень.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39081300
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Где репликация, там и распределённая БД.
Например, есть "материнская БД", и есть "дочки", периодически данные из "дочек" сливаются в "мамку". Пользователь "дочки" при работе в "мамке" не должен почувствовать никакой разницы. Т.е. права на записи должны быть настроены так, чтобы пользователь ни в коем случае не увидел чужих данных. Прав на записи в FB на уровне сервера нет. т.е. такие права надо реализовывать архитектурно.
Dimitry Sibiryakov уже определил три способа распределённой генерации уникальных ключей:
1) Составной ключ;
2) Разнесение по диапазонам;
3) UUID.

Теперь рассмотрим эти способы с точки зрения реализации прав на записи.
1) Составной ключ;
a)Ключ из двух целочисленных полей. Первое поле определяет принадлежность документа какой-либо дочке, второе поле ответственно за уникальность записи в дочке. Соответственно эти два поля определяют уникальность записи в распределённой БД.
Минусы: при связи документа и его табличной части мы должны писать что-то подобное
Код: sql
1.
2.
.... where  a.field1_id=b.field1_id and a.field2_id=b.field2_id
   and exists ('здесь определяются права конкретного пользователя на значения field1_id ') ..... 


b)Целочисленное поле идентифицирующее "дочку" и UUID.
запрос будет ~ такой:
Код: sql
1.
2.
.... where  a.field2_UUID=b.field2_UUID
   and exists ('здесь определяются права конкретного пользователя на значения field1_id ') ..... 


Плюсы: отпадает необходимость в дополнительном целочисленном поле в таблице b.

2) Разнесение по диапазонам;
Для реализации прав доступа на записи мы вынуждены будем создать таблицы соответствия диапазонов для рабочих таблиц "дочкам". Задача конечно не сложная, но трудоёмкая и кропотливая, в которой легко ошибиться. Если у пользователя права на записи из нескольких "дочек" то запросы будут монструозные.
~ так:
Код: sql
1.
2.
3.
4.
.... where  a.field1_id=b.field1_id 
   and  a.field1_id between ('определяем начало диапазона для дочки1 ') and ('определяем конец диапазона для дочки1 ')
   and  a.field1_id between ('определяем начало диапазона для дочки2 ') and ('определяем конец диапазона для дочки2 ')
 ..... 


С учётом того, что уже сказал Dimitry Sibiryakov про нарушение нормализации, реализовать такой способ найдётся желающих не много.

3) UUID.

Для реализации прав доступа на записи мы вынуждены будем добавить ещё одно идентифицирующее поле field1_id, т.е. придём к уже рассмотренному варианту 1b

Т.е. рабочих вариантов на самом деле не много, а именно два: 1a и 1b, но 1b (Целочисленное поле идентифицирующее "дочку" и UUID) мне кажется более предпочтительным.
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39081361
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Hello, Zeon11!
You wrote on 20 октября 2015 г. 15:10:56:

Zeon11> Например, есть "материнская БД", и есть "дочки"дальше не читал.
ибо высокий полёт мысли автора далек от серых будней бытия.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39081657
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
zeon11Пользователь "дочки" при работе в "мамке" не должен почувствовать никакой разницы. Т.е. права на записи должны быть настроены так, чтобы пользователь ни в коем случае не увидел чужих данных.
ересь какая-то. зачем пользователю филиальной БД работать в центральной БД, да еще видеть только данные "филиальной" БД?
Вы в курсе, что репликация в том числе предполагает, что данные реплициуются вовсе не 1 в 1? Например, зачем центральной БД абсолютно все данные филиальных БД? Чтобы что? Только ради того, чтобы юзер филиальной БД мог подключаться к обоим БД?
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39081693
zeon11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvzeon11Пользователь "дочки" при работе в "мамке" не должен почувствовать никакой разницы. Т.е. права на записи должны быть настроены так, чтобы пользователь ни в коем случае не увидел чужих данных.
ересь какая-то. зачем пользователю филиальной БД работать в центральной БД, да еще видеть только данные "филиальной" БД?
Вы в курсе, что репликация в том числе предполагает, что данные реплициуются вовсе не 1 в 1? Например, зачем центральной БД абсолютно все данные филиальных БД? Чтобы что? Только ради того, чтобы юзер филиальной БД мог подключаться к обоим БД?

Усечённая репликация - частный случай общей. Если всё работает как 1 к 1 , то будет работать и в усечённом варианте.

По поводу Центральной БД и Филиальных - видел много реальных примеров, где именно так и построено. Центр хочет видеть всё, и не хочет, что-бы один филиал видел что творится в другом филиале.
По поводу работы филиального работника на центральной БД. То-же типичная ситуация. Приезжает руководитель филиала в центр, садится за компьютер, получает аналитику своего филиала из центральной БД для разбора полётов. Может приехать и со своей аналитикой, только если отчёты не совпадут - повод для вопросов.
...
Рейтинг: 0 / 0
репликация, ПК,ФК
    #39084268
Коваленко Дмитрий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovНо таблицы соответствия это такой геморрой...

Я тут немного задумался...

Любую сложную вещь можно разделить на кусочки, каждый из которых сам по себе будет элементарным. И в конечном итоге все будет упираться в - умеешь ты это делать или не умеешь.

Таблица в которой хранится дерево адресов (страна -> .... -> улица)
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
CREATE TABLE ADDRESS_ITEM
(
 ID                  T_ID          NOT NULL,
 CLASS               T_CLASS       NOT NULL,

 OWNER               T_ID          NOT NULL,
 OWNER_CLASS         T_CLASS       NOT NULL,

 NAME                D_ADDRESS_ITEM__NAME,
 TYPE_ADDRESS_ITEM   D_ADDRESS_ITEM__TYPE    NOT NULL,

 FLAGS               T_INTEGER     DEFAULT 0 NOT NULL,

 CONSTRAINT PK_ADDRESS_ITEM
  PRIMARY KEY (ID,CLASS),

 CONSTRAINT FK_ADDRESS_ITEM_TREE FOREIGN KEY (OWNER,OWNER_CLASS)
  REFERENCES ADDRESS_ITEM (ID,CLASS),

 CONSTRAINT FK_ADDRESS_ITEM_POS_LINK FOREIGN KEY (OWNER_CLASS,CLASS)
  REFERENCES POSSIBLE_OBJ_LINK (OWNER_CLASS,CHILD_CLASS),

 CONSTRAINT FK_ADDRESS_ITEM_TYPE_ADDR_ITEM
  FOREIGN KEY (TYPE_ADDRESS_ITEM,CLASS)
   REFERENCES TYPE_ADDRESS_ITEM (ID,CLASS)
);/*ADDRESS_ITEM*/


Здесь два FK, которые нужно восстановить: FK_ADDRESS_ITEM_TREE и FK_ADDRESS_ITEM_TYPE_ADDR_ITEM.

FK_ADDRESS_ITEM_POS_LINK относится к системному уровню и его трогать не надо (идентификаторы классов одни и те же во всех базах данных).

Код, который переназначает FK в процессе восстановления
Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
<backup_script title="rpl.restore.map.table.address_item.dsx" version="1.0">
<attribute>
</attribute>
<body>
<!-- Восстановление данных.
      Локализация ссылок таблицы ADDRESS_ITEM.
                                      (C) ЛЦПИ 2000-2004. Все права защищены -->

<script language="vbscript" version="1.1">

<include name="rpl.common.const"/>
<include name="rpl.restore.utils.map_object_id"/>
<include name="rpl.restore.utils.map_type_id_ex"/>

<code>
<![CDATA[
'-------------------------------------------------------------------------------
sub rpl_restore_map_table_ADDRESS_ITEM(ctx,ai_class,ai_props)

 'определяем новый идентификатор родителя восстанавливаемой записи
 call rpl_restore_map_object_id(ctx,                                _
                                "ADDRESS_ITEM:[OWNER,OWNER_CLASS]", _
                                ai_props("owner",false),            _
                                ai_props("owner_class",false))

 'определяем новый идентификатор типа восстанавливаемого элемента
 call rpl_restore_map_type_id_ex(ctx,                                      _
                                 "ADDRESS_ITEM.TYPE_ADDRESS_ITEM",         _
                                 db_tbl_id_TYPE_ADDRESS_ITEM,              _
                                 ai_props.item("type_address_item",false), _
                                 ai_class)
end sub 'rpl_restore_map_table_ADDRESS_ITEM
'-------------------------------------------------------------------------------
]]>
</code>
</script>
</body>
</backup_script>


Полагаю нужно показать как выглядит хотя бы одна из упомянутых функций.

rpl_restore_map_object_id
Код: xml
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
<backup_script title="rpl.restore.utils.map_object_id" version="1.0">
<attribute>
</attribute>
<body>
<!-- Восстановление базы данных. Утилита отображения идентификаторов
     объектов на пространство идентификаторов БД получателя
                                      (C) ЛЦПИ 2000-2004. Все права защищены -->

<script language="vbscript" version="1.1">

<include name="rpl.common.utils"/>

<code>
<![CDATA[
'+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
'
' [oc2_obj_id,oc2_obj_class] - пара OC2-объектов свойств
' в них сохраняется локальный идентификатор объекта

sub rpl_restore_map_object_id(ctx,obj_name,oc2_obj_id,oc2_obj_class)
 const c_err_source="rpl_restore_map_object_id"

 dim msg
 dim obj_id
 dim obj_class

 obj_id    =oc2_obj_id.value
 obj_class =oc2_obj_class.value

 'обработка пустой ссылки ------------------------------------------------
 if(IsNull(obj_id) or IsNull(obj_class))then
  oc2_obj_id.value    =null
  oc2_obj_class.value =null
   
  exit sub
 end if

 'обработка ссылки на стандартный объект [0,0] ---------------------------
 if(obj_id=0 and obj_class=0)then
  exit sub
 end if
  
 'локализация идентификатора объекта -------------------------------------
 dim local_id

 set local_id=ctx.Journal.FindObj(obj_id,obj_class)

 '---------------------------------------------------------
 if(local_id is nothing)then
  msg="Отсутствует информация об объекте "& _
      obj_name&" ["&cstr_sn(obj_id)&":"&cstr_sn(obj_class)&"]"

  call err.raise(-1,c_err_source,msg)
 end if

 '---------------------------------------------------------
 if(not local_id.IsRestored)then
  msg="Объект "&obj_name& _
      " ["&cstr_sn(obj_id)&":"&cstr_sn(obj_class)&"] не был восстановлен"

  call err.raise(-1,c_err_source,msg)
 end if

 '---------------------------------------------------------
 obj_id    =local_id.NewID.ObjectID(0)
 obj_class =local_id.NewID.ObjectID(1)

 if(IsNull(obj_id) or IsNull(obj_class))then
  msg="Некорректный идентификатор восстановленного объекта "& _
      obj_name&chr(13)& _
      rpl_object_id_to_str(local_id.NewID)

  call err.raise(-1,c_err_source,msg)
 end if

 '------------------------------------------------------------------------
 oc2_obj_id.value    =obj_id
 oc2_obj_class.value =obj_class
end sub 'rpl_restore_map_obj_id

'+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
]]>
</code>
</script>
</body>
</backup_script>

...
Рейтинг: 0 / 0
20 сообщений из 20, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / репликация, ПК,ФК
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]