Распределенные базы ????

[Alex1009]

Уважаемые знатоки Axaptы, подскажите какие существуют инструменты для создания распределенной базы в Axaptе? Что-нибудь вроде выделения для каждого филиала своего диапазона ReclD и репликации баз средствами MS SQL или Oracle. Или на практике все пользуются одной базой с тонким клиентом через AOS или Web?

[George Nordic]

Не существует.
Более того, MBS очень плохо относится к подобным идеям.

Одно из решений - Axapta Retail от корус'a.
или ручками, как уже делало несколько человек.
Разруливать надо не только ReсId, но и номерные серии - обратите внимание.

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

[Андре]

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

[Alex1009]

Спасибо за ответы.
Про номерные серии - не забыл (забыл написать ).
Интересовал не сама возможность и технические сложности, связанные с реализацией, а именно общепринятый подход (как это называется Best Practices, что ли).
С уважением, Алексей.

[Lazy_Tiger]

Best Practices в данном случае - не делать распределенные системы

Axapta Retail (как у нас в компании) может работать в таком режиме, но вырвать это дело и использовать как отдельное решение... ну не знаю, за этим в корус консалтинг... но сомневаюсь.

так что остается только 2варианта:
1) не делать так (правильный ответ)
2) программировать. много.

[skof]

Делали мы такое дело, причем несколькими способами -
1. Репликация всей базы, с разделением RecID и т.д. реализорвано было под Oracle и много программировали именно под Oracle. Стандартными средствами это решить не удалось... сегодня MS SQL достиг уже большого прогресса в плане стандартных средств репликации, но не уверен что удасться настроить правильную репликацию таблицы например InventSum...
2. Рекпликация отдельных журналов и таблиц на уровне самой Аксапты - это на мой взгляд, вообще гиблая была идея - в первом случае хоть системность есть некая а сдесь вообще - как кривая выведет...
Так что если подробность нужны - пишите на мыло. Дам координаты компании которая это успешно реализовала.

[mazzy]

Цитата:

Изначально опубликовано skof
Так что если подробность нужны - пишите на мыло. Дам координаты компании которая это успешно реализовала.

Ну вот, как всегда. Как самое интересное - так в мыло.
...У нас есть такие приборы, но мы вам о них не расскажем.

Уважаемые, прекращайте подобный гиблый маркетинг.
Если есть о чем сказать - скажите прямо и открыто. Назовите имена героев, чтобы вся страна знала и гордилась.
Если нечего сказать, то и мутить воду нечего...

[Zabr]

Я участововал в создании распределенного решения на другой системе. Не на SQL. И механизмы репликации самой СУБД никак не задействовались - намеренно. Не думаю, что безумно сложно реализовать её и на Аксапте, по крайней мере, в рамках ограниченных модулей. Общая схема такая:
- для базах выделяются раздельные диапазоны для кодов не RecId, а именно кодов. Поскольку средства репликации СУБД не используются, RecId не имеют значения - записи при репликации создаются с новыми RecId. Диапазоны выделяются тем, что каждая удаленная база имеет свой прядковый номер, "знает" его и вставляет его префиксом для каждой номерной серии - вообще для каждой.
- каждая удаленная база формирует очередь из созданных, модифицированных и удаленных записей. На основе этой очереди в момент сеанса репликации формируется пакет данных для передачи. Очередь не очищается, пока не придут подтверждения из другой базы об удачной репликации.
- пакет приходит в другую базу, записи встраиваются в неё (удаленны удаляются, измененные изменяются).
- Важным является тот момент, что таблицы БД заранее разделены на 2 типа: 1 - передаваемые при репликации и 2 - не передаваемые, а пересчитываемые в момент приема пакета (в Аксапте это была бы, например, InventSum).
- Для принятых записей формируется пакет подтверждений. Он отправляется обратно и удаляет очередь в первой базе - разумеется, только по тем записям, прием которых был подтвержден. Если пакет записей или пакет подтверждений был утерян, то конечно процесс повторяется - таким образом обеспечивается целостность.

Разумется, там есть еще нюансы. Но в целом ничего безумно сложного.

[mazzy]

Спасибо, Zabr

[BOAL]

такой маленький нюанс как сопостовление, где все связки по RecId (и мест таких к сожалению полно)

если использовать стандартный импорт в Ах, то для ЕДТ RefRecId он еще связи сохранит, но в целом по системе такой метод репликации дает очень и очень частичное решение
это проще отчеты в ЦСВ файлах по мылу слать и автоматам закачивать куда надо и разностить...

но опять же, даже это и то нужно делать самим.

[Zabr]

Цитата:

Изначально опубликовано BOAL
такой маленький нюанс как сопостовление, где все связки по RecId (и мест таких к сожалению полно)

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

[mazzy]

Цитата:

Изначально опубликовано Zabr
Вот это один из тех моментов, которые толкают меня на сомнения относительно профессионализма разработчиков Аксапты. Хранение связей по RecId - это крайне безграмотный подход.

Вы судите с высоты сегодняшнего положения дел.

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

Далее, даже на заре, разработчики не думали о репликации.
Наоборот, они всеми своими фибрами думали о ЕДИНОЙ БАЗЕ, о едином хранилище.
И тогда это было на пике моды и прогресса.

В общем, не судите. Не судимы будете

[skof]

Цитата:

Если есть о чем сказать - скажите прямо и открыто. Назовите имена героев, чтобы вся страна знала и гордилась. Если нечего сказать, то и мутить воду нечего...

Уважаемый Mazzy прошу прощения за скрытую рекламу - скажу открыто делала это все компания Белсофт из Минска - так что все вопросы по получению кода и т.д. - к ним...
а подробности такие -
1. RecID-ы разделяли
2. В Oracle использовался только механизм соединения баз - репликация писалась на тригерах
3. про таблицы подобные InventSum - работало точно так как писал выше уважаемый Zabr, впрочем и другие вещи - очередь измененных записей и т.д. все очень похоже, но вставка новых, удаление старых и изменение измененных делалось не средствали Аксапты а средствами Oracle.
Аксаптой кстати даже интереснее - соблюдается многоплатформенность...
А насчет "хорошей морской практики" и т.д. скажу что ничего крамольного в репликации не вижу - если красиво реализовано и работает - то почему бы и нет?

[mazzy]

Спасибо, skof

[Волчара]

Цитата:

Изначально опубликовано mazzy

Тогда, когда принималось решение о RecID - это было очень прогрессивное решение.

Что же передового в решении по RecId?
Базовый принцип стандарта SQL заключается в том, что строка идентифицируется только значимыми полями. В этом случае RecId это спасательный круг для тех кто не умеет делать правильные структуры данных. Как то работает и ладно. А когда данные переваливают за 3 лимона записей, клиенты говорят - какая хорошая система Axapta, только работает чтото медленно. И ни какой апгрейд сервера тут не спасет.

Внимание! при правильных структурах данных у вас проблемы начнуться толко со 30 лимонов записей!!!
А при очень правильных со 100. Только не надо путать правильные и максимально нормализованные.

Впрочем, может я ошибся, может тогда еще небыло стандарта SQL - Mazzy уточни года плиз.

Извините, что ушел в сторону от темы.

[mazzy]

Цитата:

Изначально опубликовано Волчара
Что же передового в решении по RecId?

Гарантированная уникальность и малый объем.

Причем гарантированная уникальность в пределах 32 бит. Тогда 4 млрд казалось огромным числом

Цитата:

Изначально опубликовано Волчара
Внимание! при правильных структурах данных у вас проблемы начнуться толко со 30 лимонов записей!!!
А при очень правильных со 100. Только не надо путать правильные и максимально нормализованные.

Даю маячок - 32 бита. 4млрд казалось ОГРОМНЫМ числом.

Цитата:

Изначально опубликовано Волчара
Впрочем, может я ошибся, может тогда еще небыло стандарта SQL - Mazzy уточни года плиз.

Стандарт SQL был.
Но стандартной СУБД не было.
Переход на SQL был сделан в предыдущей версии - в конкорде.
А поддержка только двух стандартных СУБД - только в Аксапте.
И то изначально предполагалось, что Аксапта будет поддерживать много разных СУБД (если кто-то помнит partnerguide дамгаардовских времен и разделы для разных СУБД).
На двух СУБД остановились гораздо позже. Причем остановились маркетологи, а не технари.

Про историю можно почтитать здесь
http://axapta.mazzy.ru/articles/names/
Даты внизу статьи.

[Сисой]

Причем связи по RecID есть почти во всех известных крупных системах (и в 1С - тоже :-)). Это было очень прогрессивное решение в сравнении со связью по пользовательскому коду. Теперь изменение пользовательского ключа (№ документа, Item ID) не влияло на реляционные связи, их не требовалось обновлять. Те, кто думал о репликации, добавлял поле префикса площадки, те, кто не думал ....

[Zabr]

Те, кто думал о репликации, добавлял:
а) номер площадки, где запись создана
б) внутрисистемный уникальный код записи (не пользовательский, но и не RecId)

Позволю также не согласиться с утверждением о гарантированной уникальности RecId. Потому что здесь есть ограничения. А раз они есть, то и о полной гарантированности речь не идет. Это во-первых уникальность только в пределах одной базы, и во-вторых, уникальность только в случае если не проиводится перегрузка данных через текстовый дамп (например, в целях дефрагментации или при хранении бэкапов в виде дампов для экономии места). В этих случаях Recid'ы меняются.

[mazzy]

Цитата:

Изначально опубликовано Сисой
Причем связи по RecID есть почти во всех известных крупных системах

Это вопрос: естественные ключи против искусственных.
Эта религиозная война не скоро окончится
http://www.akzhan.midi.ru/devcorner/...ByTentser.html
См. также обсуждение этой темы на sql.ru

[mazzy]

Цитата:

Изначально опубликовано Zabr
Те, кто думал о репликации, добавлял:

Еще раз повторюсь.
Было время, когда репликация воспринималась как зло.
А модным было - единая база, всемирный интернет, на кончиках пальцев...