|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Требуется переливать данные из иерархической таблицы одной БД в другую. Иерархия организована с помощью внешнего ключа на саму себя. Планирую в таблице в БД-приемнике создать суррогатный первичный ключ, а ID сущности из оригинальной БД хранить как неключевое поле. Как правильно спроектировать таблицу - иерархию реализовать через внешний ключ (то есть в качестве ключа использовать введенный суррогатный ключ) или хранить в строке ID родительской сущности из оригинальной БД (но тогда ограничение целостности нужно будет поддерживать вручную), либо вводить суррогатный ключ и вовсе не стоит, а стоит использовать в качестве первичного ключа значения первичного ключа из таблицы-источника? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 08:25 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Interloper, А в первичной таблице, надеюсь, ключ суррогатный? Если так, зачем во вторичной добавлять еще один? Или вы планируете передавать дерево как-то частично, так что во вторичной базе оно может быть не целостным? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 09:24 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Cane Cat Fisher, В первичной таблице ключ суррогатный. Планируется передавать периодически обновления дерева. Есть вероятность, что возможно потом во вторичную таблицу будут литься данные из нескольких разных источников, тогда использование в качестве первичного ключа такового из первичной таблицы невозможно, так как приведет к коллизиям. Хотелось бы почитать про best practices в подобных задачах, чтобы понимать все pro и contra. Так-то понятно, что будет работать решение и с дополнительным суррогатным ключом и без него (если источник будет один), но желательно предвидеть подводные камни, которые таит в себе каждое из решений. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 09:36 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Тогда дерево - это вообще второй вопрос. Представьте, что у вас плоская таблица, и придумайте, что вы хотите сделать с ключами от разных источников. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 10:03 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
InterloperЕсть вероятность, что возможно потом во вторичную таблицу будут литься данные из нескольких разных источников, тогда использование в качестве первичного ключа такового из первичной таблицы невозможно, так как приведет к коллизиям. 1) Используй GUID в качестве ключа и коллизий не будет. 2) Используй deferred constraint и не будет проблем с внешним ключом при заливке. 3) Используй лог шиппинг и опять таки проблем с ключом не будет, ибо операции пойдут в том же порядке, что и в первичной БД. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 12:33 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, 1) GUID я и планирую в качестве суррогатного ключа использовать, так как в базе-источнике тип ключа - INTEGER. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 14:12 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Interloperв базе-источнике тип ключа - INTEGER. Ты что, источник не проектируешь что ли, только консолидированную?.. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 14:15 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Источник уже есть и я на него никак влиять не могу. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 16:10 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
InterloperИсточник уже есть и я на него никак влиять не могу. Тогда идея с дополнительным ключом заведомо провальная. У тебя есть на выбор всего два варианта: 1) Дополнительное поле во всех ключах, идентифицирующее БД-источник. 2) Таблицы соответствия ключей в источнике с ключом в консолидированной БД. Выбор между ними зависит от софта, которым ты будешь информацию реплицировать. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 16:29 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Почему идея провальная? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 17:00 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
InterloperПочему идея провальная? Ключ используется для идентификации записей. Если в источнике этого ключа нет, ты не сможешь точно идентифицировать запись. Представь, что из двух баз пришли записи с ключом 12345. Ты можешь назначить им разный дополнительный ключ, но при последующей репликации изменений из одной базы ты не сможешь определить какую из этих двух записей надо изменить. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2017, 18:18 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov, Так я храню ключ источника в своей таблице. Если появятся несколько источников, разумеется, придется так же хранить и инфо о таком, из какого источника пришла запись. ... |
|||
:
Нравится:
Не нравится:
|
|||
25.09.2017, 08:42 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
InterloperТребуется переливать данные из иерархической таблицы одной БД в другую. Иерархия организована с помощью внешнего ключа на саму себя. Планирую в таблице в БД-приемнике создать суррогатный первичный ключ, а ID сущности из оригинальной БД хранить как неключевое поле. Как правильно спроектировать таблицу - иерархию реализовать через внешний ключ (то есть в качестве ключа использовать введенный суррогатный ключ) или хранить в строке ID родительской сущности из оригинальной БД (но тогда ограничение целостности нужно будет поддерживать вручную), либо вводить суррогатный ключ и вовсе не стоит, а стоит использовать в качестве первичного ключа значения первичного ключа из таблицы-источника? вариант1 - используй в качестве ключа суррогатный ключ. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.09.2017, 15:46 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
InterloperТребуется переливать данные из иерархической таблицы одной БД в другую. Иерархия организована с помощью внешнего ключа на саму себя. Планирую в таблице в БД-приемнике создать суррогатный первичный ключ, а ID сущности из оригинальной БД хранить как неключевое поле. Как правильно спроектировать таблицу - иерархию реализовать через внешний ключ (то есть в качестве ключа использовать введенный суррогатный ключ) или хранить в строке ID родительской сущности из оригинальной БД (но тогда ограничение целостности нужно будет поддерживать вручную), либо вводить суррогатный ключ и вовсе не стоит, а стоит использовать в качестве первичного ключа значения первичного ключа из таблицы-источника? "Шардируйте" ключи. Т.е. выберите "шаг" ключа (обычно максимальное количество инстансов БД) А потом для каждого инстанса задаете начальное значение + шаг. Например предполагаем, что будет не более 3 инстансов. Тогда шаг ключа будет 3 Соответственно для 1-го инстанса будут ключи 1, 4, 7, 10 и т.д. Для второго 2, 5, 8, 11 и т.д. Для третьего 3, 6, 9, 12 и т.д. Тогда вопросов с уникальностью и пересечением не будет :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2017, 08:59 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Т.е. выберите "шаг" ключаДостаточно сделать интервалы: с 1 до 100тыс, с 100тыс+1 до 200тыс. и т д. Проще организовать автоинкременты. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2017, 09:42 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
LSVТ.е. выберите "шаг" ключаДостаточно сделать интервалы: с 1 до 100тыс, с 100тыс+1 до 200тыс. и т д. Проще организовать автоинкременты. Не так удобно. Так у нас на инстансах бесконечное множества. А если делить по интервалам, то есть ограничение сверху. А так все равно "автоинкремент" идет через сиквенс, а там можно сразу шаг указывать. Единственное нужно руками прописать, а не через скрипт serial/bigserial ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2017, 10:46 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
А если делить по интервалам, то есть ограничение сверху. Дык никто не мешает назначить новый интервал. Или сразу назначить интервал достаточной длины. У вас скорее всего не тыща баз. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2017, 11:22 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
LSVА если делить по интервалам, то есть ограничение сверху. Дык никто не мешает назначить новый интервал. Или сразу назначить интервал достаточной длины. У вас скорее всего не тыща баз. Зачем делать, когда можно не делать. Сиквенс пишется один раз, а за интервалами придется следить :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2017, 13:43 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
mad_nazgulТогда вопросов с уникальностью и пересечением не будет :-) Тогда будут вопросы, когда "внезапно" окажется, что максимум баз вдруг стал 4, а не 3. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2017, 14:19 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
mad_nazgulСиквенс пишется один раз, а за интервалами придется следить :-)Это почему еще за сиквенсами не нужно следить ? Было 3 сиквенса: 1,4,7... / 2,5,8... / 3,6,9... И вдруг неожиданно нужно добавить еще один. Можно конеш сделать с большим запасом. Дык и интервалы можно сделать с большим запасом. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2017, 09:36 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
mad_nazgulНапример предполагаем, что будет не более 3 инстансов. Тогда шаг ключа будет 3 Соответственно для 1-го инстанса будут ключи 1, 4, 7, 10 и т.д. Для второго 2, 5, 8, 11 и т.д. Для третьего 3, 6, 9, 12 и т.д. А как тогда выбрать запросом записи, например, только второго инстанса? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2017, 10:55 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Cane Cat Fishermad_nazgulНапример предполагаем, что будет не более 3 инстансов. Тогда шаг ключа будет 3 Соответственно для 1-го инстанса будут ключи 1, 4, 7, 10 и т.д. Для второго 2, 5, 8, 11 и т.д. Для третьего 3, 6, 9, 12 и т.д. А как тогда выбрать запросом записи, например, только второго инстанса? Делением по модулю?! :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2017, 11:48 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
mad_nazgulCane Cat Fisherпропущено... А как тогда выбрать запросом записи, например, только второго инстанса? Делением по модулю?! :-) А соответствующий индекс получится построить? Или все подряд делить-молотить? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2017, 12:27 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
Пока вопрос о нескольких инстансах не идет. Вопрос лишь в том, нормальная ли практика использовать в таблице, куда будут литься данные, новый суррогатный ключ для обеспечения иерархии. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2017, 15:38 |
|
Синхронизация иерархических таблиц между разными БД
|
|||
---|---|---|---|
#18+
InterloperПока вопрос о нескольких инстансах не идет. Вопрос лишь в том, нормальная ли практика использовать в таблице, куда будут литься данные, новый суррогатный ключ для обеспечения иерархии. Что-то мы по кругу пошли. Q: Нужен ли суррогатный ключ для обеспечения иерархии? A: Зачем вам дополнительный суррогатный ключ? Используйте тот что в льющихся данных. Q: Главная проблема в том, что если данные будут литься из нескольких инстанций, их ключи будут совпадать. Но в то же время вопрос о нескольких инстансах не идет. Так нужен ли суррогатный ключ? ... |
|||
:
Нравится:
Не нравится:
|
|||
28.09.2017, 16:06 |
|
|
start [/forum/search_topic.php?author=mediator&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
12ms |
get forum list: |
15ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
179ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
66ms |
get tp. blocked users: |
2ms |
others: | 24007ms |
total: | 24326ms |
0 / 0 |