|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Здравствуйте. Никогда не задавался вопросами репликации. Вот сейчас появилась необходимость есть две таблицы Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
ID в таблицах на генераторе. те по сути уникально. По мне (хотя могу заблуждаться) репликацию типа клиент-центр-клиент тут можно сделать по TEST2015.ID+FIRM_ID и TEST2015_SUB.TEST2015_ID+FIRM_ID И должна работать, тк FIRM_ID уникальна в пределах всех имеющихся баз. Центр раздает конфигурационный файл с указанием FIRM_ID. на клиенте добавить фирму нельзя. и даже если в центре будут добавляться документы от имени-ИД центра и test2015.ID в центре пересечется с test2015.ID клиента, то все равно сработает ПК в TEST2015. Вот только смущает избыточность в виде TEST2015_SUB.FIRM_ID. с таким пока не сталкивался. Вот по этой причине и смущает. На сколько это соответствует практике?) Спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 20:00 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Swvсмущает избыточность в виде TEST2015_SUB.FIRM_ID Зря. SwvНа сколько это соответствует практике?) Есть всего три способа распределённой генерации уникальных ключей: 1) Составной ключ; 2) Разнесение по диапазонам; 3) UUID. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 20:35 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovЕсть всего три способа распределённой генерации уникальных ключей: И, собственно говоря, второй способ это денормализация (потеря первой НФ) первого способа. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 20:41 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, тут упрощенный пример. в test2015 пк получается из 4 полей.Соответственно в sub тянутся тоже 4 поля В sub получается ФК из тех же 4 полей плюс ПК из 5 соответственно. А вот на sub ссылаются еще 10 таблиц. А раз ПК у sub из 5 полей, то чтобы в этих 10 таблицах ФК создать, что опять таки в них придется тащить эти самые пять полей. ну и ПК у них уже вырастет до 6 полей. Вот это вот и смущает ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:04 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
SwvВот это вот и смущает Не, это уже бред. Переходи на UUID-ы. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:12 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, те в предыдущем сообщении я описал все верно?) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:17 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Swvте в предыдущем сообщении я описал все верно?) Не совсем, но для начала сойдёт. Допилишь по ходу возникновения проблем. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:20 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, проблем на предмет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:27 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Swvпроблем на предмет? Доживёшь - увидишь. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:42 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, имели ввиду репликацию? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 21:52 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
SwvЗдравствуйте. Никогда не задавался вопросами репликации. Вот сейчас появилась необходимость есть две таблицы Если не очень страшно, то можешь почитать как это было сделано в одном моём проекте (2004-2008 год). Вкратце - FIRM_ID не нужен. Использовалась таблица переназначений и репликатор с программируемой логикой. В документе написано только про таблицу переназначений :). ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 22:48 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Коваленко Дмитрийбыло сделано в одном моём проекте (2004-2008 год) GUID-ы тогда уже изобрели вроде бы... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 23:00 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Dimitry SibiryakovКоваленко Дмитрийбыло сделано в одном моём проекте (2004-2008 год) GUID-ы тогда уже изобрели вроде бы... Да, и IBReplicator (2003 год) тоже уже был :) --- Я там описал, почему гуиды не помогут. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2015, 23:29 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Но таблицы соответствия это такой геморрой... Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2015, 00:09 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Hello, Dimitry Sibiryakov! You wrote on 20 октября 2015 г. 11:15:29: Dimitry Sibiryakov> И, собственно говоря, второй способ это денормализация (потеря первой НФ) первого способа. с этим можно поспорить. но мне лень. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2015, 11:15 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Где репликация, там и распределённая БД. Например, есть "материнская БД", и есть "дочки", периодически данные из "дочек" сливаются в "мамку". Пользователь "дочки" при работе в "мамке" не должен почувствовать никакой разницы. Т.е. права на записи должны быть настроены так, чтобы пользователь ни в коем случае не увидел чужих данных. Прав на записи в FB на уровне сервера нет. т.е. такие права надо реализовывать архитектурно. Dimitry Sibiryakov уже определил три способа распределённой генерации уникальных ключей: 1) Составной ключ; 2) Разнесение по диапазонам; 3) UUID. Теперь рассмотрим эти способы с точки зрения реализации прав на записи. 1) Составной ключ; a)Ключ из двух целочисленных полей. Первое поле определяет принадлежность документа какой-либо дочке, второе поле ответственно за уникальность записи в дочке. Соответственно эти два поля определяют уникальность записи в распределённой БД. Минусы: при связи документа и его табличной части мы должны писать что-то подобное Код: sql 1. 2.
b)Целочисленное поле идентифицирующее "дочку" и UUID. запрос будет ~ такой: Код: sql 1. 2.
Плюсы: отпадает необходимость в дополнительном целочисленном поле в таблице b. 2) Разнесение по диапазонам; Для реализации прав доступа на записи мы вынуждены будем создать таблицы соответствия диапазонов для рабочих таблиц "дочкам". Задача конечно не сложная, но трудоёмкая и кропотливая, в которой легко ошибиться. Если у пользователя права на записи из нескольких "дочек" то запросы будут монструозные. ~ так: Код: sql 1. 2. 3. 4.
С учётом того, что уже сказал Dimitry Sibiryakov про нарушение нормализации, реализовать такой способ найдётся желающих не много. 3) UUID. Для реализации прав доступа на записи мы вынуждены будем добавить ещё одно идентифицирующее поле field1_id, т.е. придём к уже рассмотренному варианту 1b Т.е. рабочих вариантов на самом деле не много, а именно два: 1a и 1b, но 1b (Целочисленное поле идентифицирующее "дочку" и UUID) мне кажется более предпочтительным. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2015, 14:39 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
Hello, Zeon11! You wrote on 20 октября 2015 г. 15:10:56: Zeon11> Например, есть "материнская БД", и есть "дочки"дальше не читал. ибо высокий полёт мысли автора далек от серых будней бытия. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2015, 15:12 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
zeon11Пользователь "дочки" при работе в "мамке" не должен почувствовать никакой разницы. Т.е. права на записи должны быть настроены так, чтобы пользователь ни в коем случае не увидел чужих данных. ересь какая-то. зачем пользователю филиальной БД работать в центральной БД, да еще видеть только данные "филиальной" БД? Вы в курсе, что репликация в том числе предполагает, что данные реплициуются вовсе не 1 в 1? Например, зачем центральной БД абсолютно все данные филиальных БД? Чтобы что? Только ради того, чтобы юзер филиальной БД мог подключаться к обоим БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2015, 18:09 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
kdvzeon11Пользователь "дочки" при работе в "мамке" не должен почувствовать никакой разницы. Т.е. права на записи должны быть настроены так, чтобы пользователь ни в коем случае не увидел чужих данных. ересь какая-то. зачем пользователю филиальной БД работать в центральной БД, да еще видеть только данные "филиальной" БД? Вы в курсе, что репликация в том числе предполагает, что данные реплициуются вовсе не 1 в 1? Например, зачем центральной БД абсолютно все данные филиальных БД? Чтобы что? Только ради того, чтобы юзер филиальной БД мог подключаться к обоим БД? Усечённая репликация - частный случай общей. Если всё работает как 1 к 1 , то будет работать и в усечённом варианте. По поводу Центральной БД и Филиальных - видел много реальных примеров, где именно так и построено. Центр хочет видеть всё, и не хочет, что-бы один филиал видел что творится в другом филиале. По поводу работы филиального работника на центральной БД. То-же типичная ситуация. Приезжает руководитель филиала в центр, садится за компьютер, получает аналитику своего филиала из центральной БД для разбора полётов. Может приехать и со своей аналитикой, только если отчёты не совпадут - повод для вопросов. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.10.2015, 18:37 |
|
репликация, ПК,ФК
|
|||
---|---|---|---|
#18+
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.
Здесь два 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.
Полагаю нужно показать как выглядит хотя бы одна из упомянутых функций. 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.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.10.2015, 08:26 |
|
|
start [/forum/topic.php?fid=40&msg=39080639&tid=1562566]: |
0ms |
get settings: |
12ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
others: | 285ms |
total: | 419ms |
0 / 0 |