|
|
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
Сисойiscrafmвсе же, комфорт работы в распределенной системе и в терминале - вещи несравнимые. Если к этому еще добавить простоту и низкую стоимость организации распределенной сети, то я бы конечно рекомендовать мучения с терминалами не стал. Какой еще комфорт? Любая распределенная система в сравнении с терминалом - это куча проблем, явных или потенциальных. И удорожание разработки/тестирования приложений. У терминала же при наличии стабильных каналов связи проблем всего две - пересылка файлов (печать и т.п.) и подключение некоторых хитрых устройств к клиентскому компьютеру. Ну еще стоимость терминальных лицензий важна. Зато можно экономить на клиентском оборудовании, пропускной способности сети, централизованно обновлять приложения, легко масштабировать серверные мощности. Более того, работа в терминале при грамотной организации существенно быстрее работы в локальной сети. Для этого достаточно лишь соединить пул терминальных серверов и сервер БД (или apps servers) высокоскоростной шиной. Я это проделывал неоднократно (+ внешняя дисковая подсистема промышленного уровня для БД) - скорость в сравнении с работой "по сети" впечатляющая. Не знаю о каких проблемах идет речь, и явных и потенциальных. Много лет в таких конфигурациях работаем. Приложения централизовано обновляются, серверные мощности масштабируются и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:07 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
т.е. уточните плз проблемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:08 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
"Звездная" топология синхронизации - одно из слабых мест в 1С. Необходимость выделения на техническом (не организационном) уровне явно выраженного центра ограничивает возможности работы. Тривиальный пример - межскладское перемещение. Вместо передачи с (периферийного склада1) на (периферийный склад2) приходится делать две передачи: (периферийный склад1)-->(центр), (центр)-->(периферийный склад2). Или я ошибаюсь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:09 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
sobolevТривиальный пример - межскладское перемещение. Вместо передачи с (периферийного склада1) на (периферийный склад2) приходится делать две передачи: (периферийный склад1)-->(центр), (центр)-->(периферийный склад2). Или я ошибаюсь? Можно и между узлами обмен организовать. Просто Заказчик обычно хочет иметь "общую" базу и она обычно где-то в центре топологии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:16 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
sobolev"Звездная" топология синхронизации - одно из слабых мест в 1С. Необходимость выделения на техническом (не организационном) уровне явно выраженного центра ограничивает возможности работы. Тривиальный пример - межскладское перемещение. Вместо передачи с (периферийного склада1) на (периферийный склад2) приходится делать две передачи: (периферийный склад1)-->(центр), (центр)-->(периферийный склад2). Или я ошибаюсь? Если вопрос по 7.7 - ошибаетесь. Есть возможности рулить миграцией нештатными методами (для SQL, т.к. с ДБФ уже пару лет неработаю плотно). Также есть возможность организации обмена не только по схеме "звезда", но и в любом виде нужном для клиента. Да, это потребует определенных извратов. Но главное что работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:19 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
Мне не совсем понятно, как будет идентифицироваться один и тот же объект, который приходит в центр из раздела1 и транзитом из раздела2 (т.е. в разделе2 он возник благодаря прямому переходу 1-->2). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:22 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
iscrafmт.е. уточните плз проблемы Думаю, что в стабильной ИС репликация особых проблем не вызывает. Но вот в постоянно развивающейся... При модификации приложения/структуры БД необходимо тратить ресурсы на модификацию механизмов репликации/тестирование системы разрешения конфликтов. Кроме того, требуются дополнительные настройки при подключении новых узлов. И еще: бывают случаи, когда репликация является не способом эмуляции общей БД, а частью БП (при выполнении репликации данные меняются/дополняются особым образом, идет рассылка оповещений и т.п.). При изменении БП может потребоваться изменить алгоритмы обмена. А алгоритмы учетной системы и алгоритмы обмена зачастую очень различны, могут даже использовать разные среды программирования; одновременное владение обеими технологиями требует более высокой квалификации разработчика. Для терминальных решений в рамках типовых учетных задач разработчиков более высокой квалификации не требуется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:27 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
sobolev, ??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:28 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
Я еще не упомянул про необходимость обновления приложений "на местах", связанной с этим регенерации БД. Тоже затраты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:29 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
sobolevМне не совсем понятно, как будет идентифицироваться один и тот же объект, который приходит в центр из раздела1 и транзитом из раздела2 (т.е. в разделе2 он возник благодаря прямому переходу 1-->2). А ключи в теории БД уже отменили? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:30 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
СисойsobolevМне не совсем понятно, как будет идентифицироваться один и тот же объект, который приходит в центр из раздела1 и транзитом из раздела2 (т.е. в разделе2 он возник благодаря прямому переходу 1-->2). А ключи в теории БД уже отменили? Возможны два способа идентификации факта, что объект в двух разделах есть одно и то же: 1. естественная (контекстная) идентификация. 2. идентификация по суррогатному идентификатору. Совмещать эти способы не просто. Если вы идентифицируете объект контекстно, то проблем с транзитной передачей нет, но вы должны следить за неизменностью контекста объекта (наименования товара, например). Если объект идентифицируется суррогатным идентификатором (использование UUID, как в 1с, в общем спорно, но для синхронизации - самое то), то контекстно идентичные объекты, созданные в разных разделах, будут дублироваться. Другими словами, настройка синхронизации средствами 1с представляется слишком нетривиальной задачей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 11:45 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
sobolev Если объект идентифицируется суррогатным идентификатором (использование UUID, как в 1с, в общем спорно, но для синхронизации - самое то), то контекстно идентичные объекты, созданные в разных разделах, будут дублироваться. начать нужно с вопроса о том, каким образом идентичные объекты появляются в разных разделах. Бардак. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 12:57 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
iscrafmsobolev Если объект идентифицируется суррогатным идентификатором (использование UUID, как в 1с, в общем спорно, но для синхронизации - самое то), то контекстно идентичные объекты, созданные в разных разделах, будут дублироваться. начать нужно с вопроса о том, каким образом идентичные объекты появляются в разных разделах. Бардак. Если обсуждаем одного конкретного клиента, то можно и с этого начать. Если разговор идет о тиражируемом решении, то с этим нельзя не считаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 13:14 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
soboleviscrafmsobolev Если объект идентифицируется суррогатным идентификатором (использование UUID, как в 1с, в общем спорно, но для синхронизации - самое то), то контекстно идентичные объекты, созданные в разных разделах, будут дублироваться. начать нужно с вопроса о том, каким образом идентичные объекты появляются в разных разделах. Бардак. Если обсуждаем одного конкретного клиента, то можно и с этого начать. Если разговор идет о тиражируемом решении, то с этим нельзя не считаться. без разницы. как только возникает необходимость в каком-либо объекте, то он сразу же реплицируется по сети. Что касается документов, то вообще непонятно, каким образом одинаковые объекты появляются в различных разделах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 13:18 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
iscrafmбез разницы. как только возникает необходимость в каком-либо объекте, то он сразу же реплицируется по сети. Что касается документов, то вообще непонятно, каким образом одинаковые объекты появляются в различных разделах. 1. Что значит "как только возникает необходимость в каком-либо объекте, то он сразу же реплицируется по сети"? Репликация офф-лайновая. Нет гарантии, что другой узел в произвольный момент времени доступен. 2. Дубликаты документов могут появится в разных разделах, например, по следующим причинам: -- упомянутая передача между периферийными узлами. Третий узел видит один и тот же док в разных узлах и должен как-то определить факт их идентичности. -- документ, необходимый в узле2 должен быть передан из узла1, но из-за недоступности сети передача не состоялась, а нетерпеливые операторы узла2 (им работу свою делать надо) создали его сами. Не правильно конечно, но жизнь есть жизнь. Возможны и другие причины, да и речь ведь не только о документах. Есть еще одна тяжелая проблема: объединение объектов (все ссылки на один объект передаются другому и первый после этого уничтожается). Собственно, это одно из средств борьбы с дубликатами, но для синхронизации оно тянет сложности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 13:37 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
когда в системе создается какой-либо объект, то формируется реплика. Получателей у этой реплики может быть множество, по умолчанию только собственный сервер приложений. Реплика становится в очередь и отправляется по заданному расписанию. Если какой-то узел видит что-то на каком-то другом узле, то он это же самое видит у себя, если конечно ему эта информация доступна. Вы же не подразумеваете, что "видит" это по телефону сообщили. Диктовать документы по телефону, имхо, не очень хорошая практика при работе в распределенной сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 14:07 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
У вас на сайте есть техническое описание механизма? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 14:21 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
sobolev, обзорное только ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 14:25 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
Примерно понял. Вопросы есть, но задам позже (работать надо). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.10.2010, 14:34 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
У вас компания у которой центральный офис в Москве и несколько маленьких офисов в других городах. Вы хотите организовать одну базу учета. Можно сделать терминальный доступ и все сотрудники из отделений заходят и заносят все данные в Москве. Или даже через Хамачи, если скорость канала позволяет. Есть один минус , если связь с инетом и с москвой отвалилась, все курят. Консультанты предлагают решение которое "надежно" защитит вас от обрывов связи - Репликация. Стоят 10 серверов один большой в Москве остальные в отделениях. Очень хитрая и сложная программа обменивается данными между ними, и поддерживает одинаковую базу во всех отделениях и не боится разрывов. Это теория, что на практике: рвется связь и админы не чешутся тк все у всех работает. даже интернет может работать. проходит день , и пользователи замечают, что заказы интернет магазина не приходят,а у склада стоит Газель с товаром из Москвы которая не заведена в базе. Именно в этот момент вся фирма начинает искать админа. Пока админ устраняет проблему (забыли заплатить за интернет) проходит еще 2 дня. Делать нечего из Москвы диктуют заказы интернет магазина, а Газель заносят по инвентаризации и продают. Потом интернет включают. Все нужные и ненужные данные начинают жутко двоится. Товара в компании становится на одну газель больше, удалить данные не представляется возможным тк товар отдан, деньги получены СФ напечатаны. Газель из Москвы списывают по инвентаризации. Заявки интернет магазина оставляют необработанными. Сквозной учет накрылся. Через месяц, смотря в эти данные, финансовый директор не понимает почему у него в Ростове целая газель товара списана по инвентаризации, на заявки инет магазина просто положили, а часть товара продана ниже себестоимости по "старой" цене. 3 таких сбоя приводят к катастрофическому развалу данных. Статистика, анализ KPI, становятся безумными. Я здесь , взял репликацию которая в техническом плане безупречна, и работает как часы. Если добавить "перекрестные транзакции" и ошибки программистов все становится совсем плохо, у вас появится программист за 50 000 который будет репликацию подталкивать. У нас в AVA ERP раньше тоже была репликация , но сейчас когда 10мб канал стал стоить копейки, внедрять мы ее перестали. взял здесь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 20:41 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
авторсейчас когда 10мб канал стал стоить копейкиэ-э-э... вы про какую страну говорите? где такой канал стоит "копейки"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 20:47 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
что программа планировать не в состоянии уже все поняли. Теперь узнали,что она и в системном плане не венец творения. Бахров, вы задались целью опустить ее еще ниже? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 20:52 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
iscrafmчто программа планировать не в состоянии уже все поняли. Теперь узнали,что она и в системном плане не венец творения. Бахров, вы задались целью опустить ее еще ниже? Маленький задира :) по существу что нибудь есть ? я там рассказал как все работает с ИДЕАЛЬНОЙ репликацией. У нас была суперная репликация мне жалко, что мы замочили это инженерное чудо. Каналы просто сделали свое дело. А тендер, мне кажется, надуманный , чтобы 1с за уши протащить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 20:59 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
вообще подход интересный: все, на что нет знаний, сил, возможности и т.д. реализовать - объявляется ненужным. Скоро интернет будет пестрить записками "неумех". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 21:01 |
|
||
|
Нужна система с оффлайновой распределенной БД
|
|||
|---|---|---|---|
|
#18+
bahrovя там рассказал как все работает с ИДЕАЛЬНОЙ репликацией. У нас была суперная репликация мне жалко, что мы замочили это инженерное чудо. Каналы просто сделали свое дело. судя по рассуждениям, репликация была действительно "суперная". Не пойму зачем описывать здесь свой неудачный опыт? Ну не получилось сделать нормальную репликацию, не получилось сделать планирование и т.д. Не еще все потеряно. Без планирования и с терминальным доступом тоже есть желающие работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.11.2010, 21:10 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=36919887&tid=1526335]: |
0ms |
get settings: |
11ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
70ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
| others: | 230ms |
| total: | 404ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...