Подмена данных

[f18]

Привет.
Есть задачка подменить данные, а именно
Есть две базы данных (AxDB1, AxDB2), необходимо что бы они пользовались одним номенклатурником AxDB1.InventTable. Как сделать что бы в AxDB2 везде вместо номенклатурника AxDB2.InventTable использовался AxDB1.InventTable (при этом AxDB2.InventTable - пустой).
Синхронизировать - не хочется, при AxDBn значительно возрастает потребляемое место на винте. Переписывать все механизмы отображения, лукапы и проверки тоже не хочется.

Есть идеи в подмене данных для аксапты?

Спасибо.

[Maxim Gorbunov]

Про виртуальные компании уже читали?

[f18]

Уходим от виртуальных компаний, от этого и AxDBn
Боимся блокировок ..., кол-во одновременно работающих пользователей достаточно большое (>>500), БД Oracle

[Maxim Gorbunov]

По сути, Вы пытаетесь повторить механизм работы виртуальных компаний.

[George Nordic]

Хм. Хорошо. Тогда есть такое свойство: SaveDataPerCompany.

Но я все-таки объеденил бы через виртуалки.

С Уважением,
Георгий

[f18]

При таком кол-ве пользователей (еще раз напомню что работают одновременно), работа с виртуальными компаниями представляется весьма затруднительной, т.к. прийдется разруливать проблемы с блокиовкой минимум таблиц InventTrans, InventSum.

Я согласен с тем что это подмена виртуальных компаний.

Идеи есть?

[Maxim Gorbunov]

А вы их что, тоже в виртуальную компанию собираетесь засовывать?

[George Nordic]

Да Вы что???? InventTable / InventTableModule etc - общие, а вот проводки по складу, простите - это уже уникальные данные для каждой компании!!!

С Уважением,
Георгий

[f18]

Нет, эти таблицы не могут быть в виртуальных компаниях (по крайней мере в моем случае), но ..., на сколько я понимаю, если идет блокировка части таблицы/всей таблицы (а в случае если мы используем виртуальные компании то все данные хранятся в одной таблице - только с разным значением dataAreaId) и под блокированные данные могут попасть данные из разных компаний, что значит - все сидим и ждем пока исходный процесс не разблокирует данные. Или я ошибаюсь?

[Михаил Андреев]

Цитата:

Изначально опубликовано George Nordic
Да Вы что???? InventTable / InventTableModule etc - общие, а вот проводки по складу, простите - это уже уникальные данные для каждой компании!!!

С Уважением,
Георгий

Делали и так, и даже ещё интереснее с 80% общих таблиц, ничего сложного. А для наших реалий бывает необходимо.

2 f18:
Вы уверены, что Ваша самостоятельная доработка будет надёжнее штатных средств Аксапты?

Цитата:

[Уходим от виртуальных компаний, от этого и AxDBn
Боимся блокировок ..., кол-во одновременно работающих пользователей достаточно большое (>>500), БД Oracle

Не понял, а как Вы пытаетесь уйти от блокировок и каких?

[Михаил Андреев]

Цитата:

Изначально опубликовано f18
Синхронизировать - не хочется, при AxDBn значительно возрастает потребляемое место на винте.

Вы ещё не видели таблиц складских проводок и сопоставлений.

[f18]

Думаю что есть масса способов решить мою задачу (а конечная задача что бы пользователи работали комфортно, выполяли свои бизнес задачи наиболее оптимальными средствами (спосабами), построенная система была легко поддерживаема и маштабируема), но ...
Для того что бы не бросаться в омут с головой (что не нужно не мне ни пользователям) в данный момент по списку вариантов построения системы вариант вот с такой загагулиной и необходимо описать все его плюсы и минусы.

Решение с виртуальными - это одной из рассматриваемых решений, оно в конкретном случае не плохое и не хорошее - просто решение, в котором я боюсь столкнутся с производительностью работы системы.
Есть стандартные способы обмена данными (Galaxy ...), до них очередь по списку еще не дошла, но обязательно дойдет ...

Теперь конкретно по (Вы уверены, что Ваша самостоятельная доработка будет надёжнее штатных средств Аксапты?
) - нет не уверен, я просто рассматриваю и оцениваю варианты.

(Не понял, а как Вы пытаетесь уйти от блокировок и каких?)
При большом кол-ве пользователей возникают ситуации когда несколько пользователей работают с одними и теми же таблицами, так в моем случае (Логистика) одними из самых обновляемых таблицами будут InventTrans, InventSum, а в случае блокировки пользователем этих таблиц - остальные пользователи будут ждать пока таблицы разблокируются (т.е. при попытки вставить запись в строки заказов или при разнесении заказа - будет вертется курсов в виде песочных часиков - до тех пор пока процесс заблокировавший данные не закончится. К сожалению иногда эти процессы длятся очень долго, будет ли ждать пользователь?) Если сделать разные базы данных то кол-во блокировок и времени ожидания пользователей можно сократить в разы.

Другими словами ... Интересует вариант реализации именно описанный в первом вопросе.

Спасибо.

[f18]

2 Михаил Андреев
Вы ещё не видели таблиц складских проводок и сопоставлений.

Видел (не первый раз замужем).

[Maxim Gorbunov]

Цитата:

Изначально опубликовано f18
Нет, эти таблицы не могут быть в виртуальных компаниях (по крайней мере в моем случае), но ..., на сколько я понимаю, если идет блокировка части таблицы/всей таблицы (а в случае если мы используем виртуальные компании то все данные хранятся в одной таблице - только с разным значением dataAreaId) и под блокированные данные могут попасть данные из разных компаний, что значит - все сидим и ждем пока исходный процесс не разблокирует данные. Или я ошибаюсь?

В общем случае, конечно, зависит от запросов, но обычно вся таблица не блокируется.

[MironovI]

В самом деле не понимаю от каких таких блокировок вы спасаетесь - кто у вас справочник номенклатур блокирует?.. Либо постановка задачи не полна и планируется так же поступить с другими таблицами?

[George Nordic]

Тем более, если у Вас - Oracle.

[f18]

Цитата:

Изначально опубликовано Maxim Gorbunov
В общем случае, конечно, зависит от запросов, но обычно вся таблица не блокируется.

Согласен.

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

[MironovI]

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

[f18]

Цитата:

Изначально опубликовано MironovI
В самом деле не понимаю от каких таких блокировок вы спасаетесь - кто у вас справочник номенклатур блокирует?.. Либо постановка задачи не полна и планируется так же поступить с другими таблицами?

Как раз за номенклатурник я и не беспокоюсь, я беспокоюсь за проводки!

Наверное разговор ушел несколько не в то русло ... и господин MironovI абсолютно прав - все стало не понятно ..

Для того что бы не путаться предлагаю не обсуждать в данной теме вопросы касающиеся выбора метода построения системы (виртуальные компании ...), а рассмотреть чисто прикладную задачу замену таблицы одной БД таблицей из другой БД без дублирования (т.е. интиресуют способы реализации).

Спасибо.

[f18]

Цитата:

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

К сожалению я не боюсь (боятся - это просто), а описываю конкретный вариант реализации. Кто сказал что нужно данные сливать в ЦБ?, я говорил лишь о том что у них должны быть общие справочники.