Попробую рассказать о принципах оффлайновой работы 1С.

[mazzy]

Цитата:

Сообщение от Reaper

...не стремятся устроить федеральную торговую сеть...

Цитата:

Сообщение от Logger

Ну, обслуживание больших комплексов тоже стоит дороже

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

Все проще и дешевле.

[Logger]

Как правило ларек с распределенкой бывает дешевле

[gl00mie]

Цитата:

Сообщение от mazzy

Сколько стоит соверменный сервер? 5000-7000 долларов. Разово.

"Сколько стоит современный грузовик?" Это разговор ни о чем, потому что разброс может быть очень большим, кроме того, если организовывать работу кучи народа удаленно на одной площадке, то одним сервером не обойтись - серверов, по крайней мере, виртуальных, нужно несколько (СУБД, сервер приложений, терминальный сервер, если работа будет в 4-хзвенке), нужны стойки под них, нужны UPS'ы, шустрое сетевое оборудование для связи всего этого хозяйства, возможно, какое-нить NAS для хранения данных, нужно где-то делать резервные копии больших объемов данных, etc, плюс, опять же, нужно некоторое резервирование, чтобы все разом не встало из-за одного звена цепи.

Цитата:

Сообщение от mazzy

Сколько стоит поддержка специалистов, которые разгребают конфликты репликации? Каждый месяц.

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

Цитата:

Сообщение от mazzy

Можно подумать, что распределенка не приводит к простоям. Обслуживание распределенки тоже необходимо выполнять.

Приводит, наверно, но вероятность того, что встанет вдруг всё, куда меньше, чем при использовании централизованной площадки. Для какого-то вида бизнеса простой в течение дня или даже двух может быть приемлем, а для какого-то (той же розницы) даже пара часов простоя в течение рабочего дня может обернуться очень большими убытками. В общем, мне кажется, универсальных решений ("серебряных пуль") не бывает - где-то больше подходит распределенная "асинхронная" обработка, и с решением для оффлайновой работы 1С вполне может занять достойное место в соответствующей нише.

[mazzy]

Цитата:

Сообщение от Logger

Как правило ларек с распределенкой бывает дешевле

угу. я об этом и говорю.
в спорах 1Сники приводят либо "ларек", либо "федеральную сеть".
20 ларьков уже выбивается. 4-5 филиалов в крупных городах - тоже.

Цитата:

Сообщение от gl00mie

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

Э-э-э....
gl00mie, а ты сейчас "вообще" рассуждаешь или конкретно про 1С?
никогда не сталкивался, когда 1С не успевает за ночь обработать обмен?
никогда не сталкивался, с пропажей документов и/или элементов справочников в 1с?

тема: "Попробую рассказать о принципах оффлайновой работы 1С"

вот Reaper начал рассказывать что-то из реальной жизни.
и тут же увели в противостояние "ларек"-"федеральная сеть".
Давайте конструктивнее.

[miklenew]

Пипец пароль забыл
Ну ладно раз зашёл, оставлю свои пять копеек.
В 1с есть два вида обмена распределёнка и универсалка.
1) Рапределёнка - это механизм системы. Работает в обе стороны. Но с условием, что и первой точке и второй будет использоватся всё тоже самое.
Ввели данные в первой точке, ап и они появились и второй. И наоборот. Чем чаще обмен тем выше актуальность данных.
Понятно что такой механизм удобен для независимых данных.
Т.к. в 1с отсутствует таблицы остатков в привычном для аксы виде. Т.е. место остатков и проводок - две таблицы проводок. Остатки каждый раз достаются схлопыванием. Но засчёт встроенных механизмов такие как итоги, агрегаты, виртуальные таблицы механизм работает быстро(в зависимости от объёмов). Если для организации не критично есть ли товар или нет, то этим же механизмом можно создавать и движения.
2) Универсалка - это уже механизм разработчика. В первом можно вообще код не писать. Во втором от и до пишет разработчик. А такие объекты конфигурации как планы обмена, чуть облегчают ему жизнь. Т.е. разработчик забирает ту информацию какая ему нужна. Например документы. И уже сам решает что с ней делать. И обратно может отослать результаты его телодвижений.
На распределёнку разработчику достаточно и 5 минут, на универсалку может и несколько дней в зависимости от сложности задачи. Играясь этими двумя механизмами можно сделать любой обмен. А степень участия того и другого зависит от бизнес процесов клиентов.
Вот. Как то так.

[mazzy]

Цитата:

Сообщение от miklenew

Пипец пароль забыл
Ну ладно раз зашёл, оставлю свои пять копеек.
В 1с есть два вида обмена распределёнка и универсалка.
1) Рапределёнка - это механизм системы. Работает в обе стороны. Но с условием, что и первой точке и второй будет использоватся всё тоже самое.
Ввели данные в первой точке, ап и они появились и второй. И наоборот. Чем чаще обмен тем выше актуальность данных.

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

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

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

Цитата:

Сообщение от miklenew

Понятно что такой механизм удобен для независимых данных.

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

Цитата:

Сообщение от miklenew

Т.к. в 1с отсутствует таблицы остатков в привычном для аксы виде. Т.е. место остатков и проводок - две таблицы проводок. Остатки каждый раз достаются схлопыванием. Но засчёт встроенных механизмов такие как итоги, агрегаты, виртуальные таблицы механизм работает быстро(в зависимости от объёмов).

Блин, типично наше осознание уникальности.
А все как раз наоборот: Есть у других. И гораздо лучше.

Таблицы остатков в 1С списаны с запатентованого в Скале механизма.
Уж сколько раз писали об этом. В том числе и на этом форуме.

В аксапте конечно же есть подобные таблицы. Называются LedgerBalances*.
Только в отличие от 1С, в Аксапте есть не только записи об оборотах в текущих периодах, но есть также записи в так называемых периодах "начальных остатках".
Поэтому Аксапте надо суммировать (схлопывать) обороты не от начала времен, а только в пределах финансового года.

Кроме того, в последних версиях Аксапты в одном периоде может быть не одна запись, а несколько (до 16) с различными хэшами. Оборот за период вычисляется как сумма всех записей за период. В результате, за счет увеличения объема таблицы с промежуточными оборотами, разработчики кардинально уменьшили вероятность возникновения блокировок в этой таблице при создании проводок.

А с проблемой роста таблиц с промежуточными итогами в 1С в Аксапте борятся двумя способами:
= галочкой "переносить аналитику в следующих финансовый год".
= аналитические итоги хранятся в дополнительных модулях и в дополнительных таблицах (некий аналог 1Совских регистров).

Цитата:

Сообщение от miklenew

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

Ну да, ну да. В Аксапте это AIF.

Цитата:

Сообщение от miklenew

Играясь этими двумя механизмами можно сделать любой обмен. А степень участия того и другого зависит от бизнес процесов клиентов.
Вот. Как то так.

А разве они могут работать ОДНОВРЕМЕННО?
Поправьте меня, если я ошибаюсь: работает либо "распределенка", либо "универсалка". Ведь так?

[miklenew]

Цитата:

Сообщение от mazzy

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

да.

Цитата:

Сообщение от mazzy

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

Нет. Если транзакция не прошла, означает ли это крах бд. Пройдёт ситуация помешавшая пройти транзакции и она проскочит.

Цитата:

Сообщение от mazzy

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

Повторяемость разрешается префиксами в номерах. маг1- М1_xxxxx, маг2 - M2_xxxxx

Цитата:

Сообщение от mazzy

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

Если запрещён отрицательный склад, отрицательный кредитный лимит, то да. Хотя чесно я могу тут ошибатся. Сисой придёт, свои пять копеек дообавит

Цитата:

Сообщение от mazzy

Блин, типично наше осознание уникальности.
А все как раз наоборот: Есть у других. И гораздо лучше.
Таблицы остатков в 1С списаны с запатентованого в Скале механизма.
Уж сколько раз писали об этом. В том числе и на этом форуме.

Серёг, я не эту цель преследовал. Я сказал это, чтоб было представление о том почему проводки в 1с при определённых условиях можно тупо перенасить на уровне системных механизмов. Чтоб не было вопросов, да как же так полетят все остатки или система знает как с какими остатками надо работать сама (типо суперумная, а это и не требуется).

Цитата:

Сообщение от mazzy

А разве они могут работать ОДНОВРЕМЕННО?
Поправьте меня, если я ошибаюсь: работает либо "распределенка", либо "универсалка". Ведь так?

Могут. Они работают одновременно. Что можно автоматом перенести, переносим системой, остальное допиливаем напильником(универсалкой)

[Reaper]

Сейчас чуть разверну тему с технической стороны, коль скоро такой интерес возник.
Начнем с того, что как такового одного механизма для обмена нет. Есть два независимых механизма в платформе:

1. Служба регистрации изменений
2. Механизм сериализации объектов платформы и работы с XML

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

Второй механизм используется только для полных обменов. Сильная его сторона в том, что он делает выгрузку/загрузку с очень достойной скоростью (по сравнению с универсалкой, поясню ниже). В этом же и его минус - обмен может длиться 5 минут вместо 4-х часов, но на все время этого обмена блокируются физические таблицы службы регистрации изменений. А организованы они "в лоб" - на каждый узел репликации одна таблица. Блокировка накладывается исключительная на всю таблицу. В итоге получаем замирающую на время обмена базу.

Теперь об универсалке. Конфигурация "Конвертация данных" предоставляет технологию визуального конструирования правил репликации. Но механизмы работы с этими правилами, предоставляемые фирмой 1С, не используют механизма сериализации - запись XML осуществляется посредством WSH. Скорость обмена при таком подходе ниже в разы, особенно загрузка, т.к. платформа не считывает объект целиком, а создает его реквизит за реквизитом. Но с другой стороны, при таком подходе обращения к службе регистрации разбиваются на малые порции и длительность блокировок резко меньше. Кроме того, универсалка, вкупе с собственными алгоритмами работы со службой регистрации изменений, позволяет разработать абсолютно произвольную топологию обмена, а так же и правила преобразования данных и ограничения миграции. Справедливости ради скажу, что и при простой распределенке миграцию можно ограничить, но в типовых это сделано только в БП для обмена "по организации".

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