|
|
|
нумерация извне
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Ситуация (упрощенно). Есть главная БД1, в ней таблица Т1. И есть на внешнем сервере интегрированная с ней выделенная БД2 с таблицей Т2. И некоторым образом настроено, что БД1.Т1 частично синхронизируется по БД2.Т2, т.е. БД1.Т1 содержит некоторую выборку записей БД2.Т2. В БД2.Т2 и БД1.Т1 есть ключ - id (u_int <пользовательский тип данных int>), который в БД2.Т2 также еще и счетчик (причем в БД1.Т1 значение id имеет разрывы, поскольку - только выборка). Вот возникла логика по определенному принципу БД1.Т1 дополнять записями, не происходящими из БД2.Т2. И сразу всплыла проблема нумерации этих "собственных" записей. Хочется найти какой-то способ, как получше это сделать. Может быть, кто-то сталкивался с подобной задачей и уже ее успешно решил, или наоборот, напоролся на какие-то камни. Ограничения: *надо действовать в рамках этого ключевого поля, новые добавлять нельзя, т.к. существует большая группа объектов, для которых необходимо и достаточно использовать это поле. *опрашивать БД2 для генерации значения нельзя. Пока варианты очень неэстетичные: 1) использовать отрицательное значение ключа - не годится (для u_int есть rule на > 0 , менять правило нельзя) 2) время от времени заранее требовать с БД2 генерировать массив пустых записей и сбрасывать в БД1 для последующего заполнения. 3) поменять тип - например, а обычный int (и писать отрицательные значения), строку (и писать буквенные символы), дроби (и писать туда дробные значения). Что присоветуете? Спасибо. ps я понимаю что задача выглядит "криво", но это не от меня зависит. Сейчас я имею стабильно работающую систему, которую нежелательно серьезно модифицировать (как раз "мой" фрагмент очень плотно используется 24*7*365), но при этом надо развивать, добавляя новые функции. При этом испоьлзуемые технологии БД и обмена данными между БД также несколько устарели, но это то ограничение, которое надо учесть как данность, и работать в его рамках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2008, 12:55 |
|
||
|
нумерация извне
|
|||
|---|---|---|---|
|
#18+
Что нельзя использовать отрицательные ключи - это жаль, конечно. А в пункте 3 не тот же вариант рассматривается? - поменять тип - например, а обычный int (и писать отрицательные значения) И все-таки, что мешает завести свой первичный ключ для таблицы БД1.Т1 ? А что существует большая группа объектов, для которых необходимо и достаточно использовать это поле, т.е., поле, заполненное значениями из таблицы БД2.Т2 - так и пусть себе они его используют дальше. Для записей не из таблицы БД2.Т2 будет в этом поле NULL. Запросы изменить с учетом этого условия. Да и при сопровождениии может понадобиться узнать происхождение той или иной записи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.07.2008, 15:37 |
|
||
|
нумерация извне
|
|||
|---|---|---|---|
|
#18+
разнесите идентификаторы в разных БД по диапазонам. Многие СУБД предоставляют встроенную возможность разнесения. Например, в mssql identity очень легко настроить для разнесения по диапазонам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.07.2008, 19:49 |
|
||
|
нумерация извне
|
|||
|---|---|---|---|
|
#18+
Можно GUID использовать для ключа - тогда вообще заморок никаких. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.07.2008, 00:19 |
|
||
|
|

start [/forum/topic.php?fid=32&fpage=100&tid=1543748]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
1ms |
| others: | 257ms |
| total: | 386ms |

| 0 / 0 |
