|
Совместные таблици
|
|||
---|---|---|---|
#18+
Привет всем. FB4. Есть у меня главная база и другие. В главнои базе есть несколько таблиц к которим в read only режиме нужен доступ из других баз. Шас сделал ето через execute statement. Всё работает, но задумался - а можбить можно как то так сделать что в главнои базе ети таблици делаю как External и потом их прикручиваю как то к остальным базам ... Мож чуш несу, скажие чтоб зря время нетерять, можно так вообше - да или нет ? WBR Janex ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 17:49 |
|
Совместные таблици
|
|||
---|---|---|---|
#18+
Можно эти базы загнать в режим R/W replica и настроить залитие этих таблиц из главной. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 18:10 |
|
Совместные таблици
|
|||
---|---|---|---|
#18+
Dimitry Sibiryakov Можно эти базы загнать в режим R/W replica и настроить залитие этих таблиц из главной. Что то недогоняю :( Все базы разные, в главнои лежат пара таблиц которы должны бить как бы совместные, типо в главнои базе таблица STAFF, там она коректируется, добовляются новые записи итд а остальные базы тож должны юзать в RO режиме ету таблицу... С репликациеи там ето вроде как непрокатит... ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 18:16 |
|
Совместные таблици
|
|||
---|---|---|---|
#18+
Janex, нету в ФБ внешних таблиц которые к другим базам подрубаются. Но можно сделать относительно прозрачную ХП, которая для SELECT запросов всё равно что таблица, а внутри неё execute statement. Вариант DS тоже интересный. Никто не мешает не давать на эти таблицы никаких прав кроме SELECT З.Ы. В 4.0 для ES ON EXTERNAL можно настроить пул соединений для ускорения повторного доступа. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.09.2021, 18:25 |
|
Совместные таблици
|
|||
---|---|---|---|
#18+
А линки вообще имеются в планах? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.09.2021, 09:30 |
|
Совместные таблици
|
|||
---|---|---|---|
#18+
+1 за репликацию. Тут ведь какое дело. С одной стороны, если пофилософствовать по Дейту, то один справочник в центральной базе - это хорошо, нет парадоксов дублирования. С другой стороны а) попадаешь в зависимость всех подсистем от доступности центральной базы в каждый момент времени, бе) джойны и всё такое идут лесом, ве) тормозишки по-любому. А тут - шедулер время от времени докачивает новизну и всё. Не смог провести какой-то сеанс - ну, исходя из названия таблицы STAFF - какова вероятность того, что появился новый сотрудник и в сателлитных базах срочно и всенепременно нужно работать именно с записью о нём? И какая беда произойдёт с того, что старый сотрудник волосы перекрасил, а сателлиты узнают об этом только через полчаса? В конце концов, капу приделать - разослать свежие данные прямо сейчас, сразу после ввода. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.10.2021, 18:07 |
|
|
start [/forum/topic.php?fid=40&fpage=4&tid=1559927]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
57ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
44ms |
get tp. blocked users: |
2ms |
others: | 248ms |
total: | 398ms |
0 / 0 |