Сначала тезисно пройдусь по ТЗ:
1) ПО торгово-производственное, предполагается участие в репликации, в основном, не более 10-ти машин, за редким исключением - максимум нескольких десятков машин. Типичная конфигурация: две независимые точки, на одной 3-5 машин в локальной сети, на другой 3-5 машин операторов.
2) Базы все FB 2.5 (хотя возможен переход на тройку).
3) Репликация планируется асинхронная, через существенные промежутки времени (раз в 30-60 мин, например, в основном, обмен заказами).
4) Обмен через FTP-папку, xml-файлами, в которых содержатся "пакеты изменений". Выгружаются две сущности: справочники и заказы.
5) Все изменения записей будут отслеживаться в триггерах и вноситься в таблицу выгрузки.
5) Репликация Master-Master.
6) Дабы минимизировать конфликтные ситуации и обеспечить ссылочную целостность - физически данные не удаляются ни в одной таблице. Только скрытие, по boolean-полю DELETED.
7) Заказы, созданные на "другой" торговой точке не подлежат редактированию. Только "свои".

Теперь подробнее.
Схема Master-Master предполагает ряд тонких моментов, самый очевидный из которых - как быть с генераторами?
Предполагаю так: в отношении справочников - генераторы должны быть разумеется идентичны на всех машинах, участвующих в репликации. Что же до заказов - то тут генераторы на каждой машине свои конечно, однако чтобы был порядок, и в плане визуального восприятия заказов, и в отчетах\анализе - используются уникальные для каждой торговой точки integer-идентификаторы.

Далее, что сделать, чтобы одновременные изменения в справочниках на разных машинах не повлекли конфликты?
Тут вижу такое решение - монопольный доступ. Причем, прежде чем редактировать любой справочник, ПО должно обратиться к серверу (лучше реализовать через HTTP-REST-запрос? или можно также по ftp?) на получение состояния некоего флажка блокировки редакции справочников. Если он (флаг) установлен и известно кем - значит всем остальных доступ на редакцию сейчас запрещен. Соответственно, тот кто этот флаг возвел, он же его и снимает после завершения редактирования справочников. Финализация этого процесса предполагает выгрузку файла с изменениями и снятие флажка. Решение выглядит негибким, однако для данной задачи, возможно, вполне подходит, поскольку попытка одновременной редакции справочников будет крайне редким явлением.

Поскольку новичок в теме, прошу совета отцов. Что упустил, что посоветуете...

Ivan_PisarevskySoftologic4) Обмен через FTP-папку, xml-файлами, в которых содержатся "пакеты изменений". Выгружаются две сущности: справочники и заказы.Какая-то лишняя сущность.

Диапазоны идентификаторов в ИНТ64, ГУИД по вкусу.

Купи готовый репликатор, это заметно дешевле разработки своего.
Там просто море сельхозинвентаря припрятано.

Не совсем понял почему лишняя...
И где продают дешевые репликаторы для тиражируемого софта с неограниченным числом лицензий?
IBReplicator что то совсем недешев: https://www.ibphoenix.com/shop/category/2

Ivan_Pisarevskyftp и xml лишние. ну по крайней мере мы не используем. парсить xml в поллямя строк то еще удовольствие. а вот если заготовить сразу пачку стейтметов ничего парсить не потребуется. у нас репликатор сам обменивается через сокеты запакованными пачками, фтп не нужен.

насчет ибрепликатора спроси прямо у Сибирякова, он же тут, никуда не делся.

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

У нас репликатор свой, затачавали по себя.

Ну ок, понял как без xml, со стейтментами... даже в принципе, с бинарниками понимаю, как YuRock предлагает. Но не понял как без ftp обойтись? Базы же географически раскиданы, обмен то в любом случае через интернет делать. Писать в MySQL-базу на сайте через php-запросы чтоль? Или новомодные яндекс-диски, гугл-драйвы использовать?

Ок, спасибо большое всем за помощь!
Тогда такой вопрос - вообще какой ценник у такого рода задачи? Понимаю, что вопрос риторический, все по разному себя оценивают, однако все же... быть может есть некая минимальная оценка? Кто за сколько бы взялся?

YuRockУже говорил. Это не простая задача. Да еще и начать нужно с написания и согласования ТЗ. В итоге - будут месяцы работы (квалифицированного программиста, высокооплачиваемого), потом поддержка.
Не знаю, сколько стоят готовые решения, но очень вероятно, что дешевле.
Про непростоту задачи я понимал с самого начала, и что готовые решения дешевле тоже. Хотя, повторюсь - для тиражируемого ПО с неограниченным числом лицензий... Это большой вопрос. И готовое может потянуть тыщ на 5 евро в год, как HQBird в Enterprise-редакции со встроенным репликатором.
Таки может кто минимальную планку назвал бы примерную, а? Для ориентиру...

Dimitry SibiryakovSoftologicНо не понял как без ftp обойтись?

VPN + прямое подключение, например. На ваших объёмах должно хватить.
VPN + SMB тоже неплохой вариант.
FTP имеет проблему с атомарностью передачи, её надо будет обеспечивать дополнительными
средствами.

Да, VPN + прямое подключение, вероятно, оптимальный вариант.

YuRockSoftologicТаки может кто минимальную планку назвал бы примерную, а? Для ориентиру...Ну, пожалуйста. Если какой-то нищеброд типа меня согласится сделать тебе репликатор (свой адаптировать к твоей системе), это будет пару десятков килобаксов стоить. Ориентировочно, а так будет ++.
То есть от миллиона рублей так очень примерно. И это нищебродская оценка, я полагаю ?:)

Гаджимурадов РустамЧую, нарисовывается тендер.

Похоже обламаю всех сейчас :)
Проект-долгострой. Делается по-дружески практически. Поэтому термин "бюджет" не совсем уместен. Собственно, поэтому и спрашивал советов, как бы самому научиться то полезно.

Dimitry SibiryakovSoftologicПроект-долгострой. Делается по-дружески практически.

Очередная автоматизация, все установленные экземпляры которой при смерти или исчезновении
друга автоматически превращаются в тыкву. Ню-ню...

Дмитрий, полагаю, со знанием дела говорите? Деталей взаимодействия мне не с руки раскрывать, да и дело это прошлое... Скажем так, есть обязательства определенные, которые надо закрыть. Лучше наверное так сказать.

Старый плюшевый мишкаSoftologicпропущено...

Дмитрий, полагаю, со знанием дела говорите? Деталей взаимодействия мне не с руки раскрывать, да и дело это прошлое... Скажем так, есть обязательства определенные, которые надо закрыть. Лучше наверное так сказать.

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

Гаджимурадов РустамКореец, аднака.

Кто? :)

Гаджимурадов РустамКореец, аднака.

Пардон. Не сразу врубился :)

kdvSoftologicIBReplicator что то совсем недешев
вы меня извините, но 280 баксов за Сервер + реплику (150 + 130 =280 баксов) это даже в зажопинске максимум месяц работы одного программера.
Один месяц зарплаты, а лицензия - бессрочная.
Это если штучно. А пакетами там со скидкой. Вы считаете, что репликатор такого уровня можете сделать за неделю? Ну или если вам такого уровня не надо, то тогда сваяйте нечто ограниченное за неделю, баксов за 80-100.
Кроме того, меня нереально бесит, когда программист (наемный работник) начинает оценивать затраты вместо владельца бизнеса.
При всем уважении, ну не надо этого делать. Вы же сами своим коллегам-программистам рубите нахрен продажи софта. Причем на пустом месте.
К тому же, этот софт контора будет покупать не из вашего кармана. Разве нет?
"Это дорого" - решил программист. "Да херня какая-то, оплатим" - решил директор. Только директор не узнал про цены, потому что программист решил что "дорого". А потом сам уколупался на полгода, чем превысил стоимость готового решения раза в 3-4.
Дмитрий, при всем уважении к вам, все же немного сгущаете краски... Конечно я не сделаю репликатор такого уровня за неделю. Это первое, второе - мне нужно действительно нечто попроще, о чем я несколько раз говорил. Третье - я не наемный программист, я был когда то совладельцем проекта, поэтому имею некоторые полномочия считать и "за того парня" (читай: владельца бизнеса).

kdvSoftologic,

тогда откуда фраза что 280 баксов это дорого? Ладно если софт однопользовательский, и стоит 3-7 тыс руб. Но репликация-то делается для распределенных контор, где такие деньги - не деньги для автоматизации...
о том и речь :) софт хоть и многопользовательский, но ценник за одно койко-место рабочее место действительно планируется в районе 3-5 тыщ. ПО для мелких торговцев-лавочников, у которых предполагается "одна-две-несколько точек по городу".

kdvSoftologic,

тогда нефиг смотреть в сторону ИБрепликатора, ни по цене, ни по функционалу - к вашему решению он не уперся.
А с другой стороны - вот 1с, минимальное 3к руб. Репликация у него есть? нет. А почему у вас за те же деньги есть?
Это вообще для кого? Зачем нищебродство плодить? Вы думаете, что если ваше решение будет стоить тыщу руб, его купят миллион пользователей? Ведь нет же :-)
Если одно место 3-5 тыщ, то с репликацией даже для 2-3 мест оно ну никак те же 3-5 тыщ стоить не может. И этому мелкому лавочнику это надо попытаться объяснить.
Хотя, ценообразование это стрёмная штука. Однако, все равно, при цене 3-5 тысяч сколько штук надо в месяц продавать, чтобы нормально жить и дальше разрабатывать в течение года?

p.s. К слову - буквально три дня вот у меня пользователи решения Х на ФБ спрашивали - а как для решения Х прикрутить репликацию? Я говорю - если не предусмотрено, то никак. И ведь не уговорил, не понимают.
Так я ж и не смотрю. Повторюсь - я когда то на идеологическом старте имел к проекту некое партнерское отношение, но давно ушел в сторону, сейчас я ничего не решаю, кроме как некоторых технических вопросов, поскольку есть определенные обязательства. Собственно, чем и занимаюсь в этом топике. Спрашиваю, советуюсь.

YuRockSoftologicсофт хоть и многопользовательский, но ценник за одно койко-место рабочее место действительно планируется в районе 3-5 тыщ. ПО для мелких торговцев-лавочниковА, так тебе просто совсем другой вид "репликации" нужен.
В меню программы сделай пункт "Отправить сменный отчет", и там формируй свой xml или json или dbf или что угодно (по закрытым невыгруженным периодам) для загрузки где-то.
Всё, за такую цену этого более, чем достаточно.
Да, вроде того. Я ж говорил, упрощенная модель.

dvimПО для мелких торговцев-лавочников, у которых предполагается "одна-две-несколько точек по городу".

Имхо для такого По использовать репликацию силами СУБД - зло.
Лучше отдельно реализовать загрузку-выгрузку данных и справочников.
Репликация и решение конфликтов требует квалифицированного ИТ
А чем отличается одновременная выгрузка и того и другого вручную от автоматики? Ведь пользователь-лавочник далеко не каждый продвинутый спец. Что изменится от того что он сам будет делать выгрузку-загрузку.

Генераторы, как упоминал, в справочниках будут одинаковыми на всех тачках. Про генераторы в заказах - составные посоветовали. Физически данные нигде не будут удаляться, только скрываться. Где основные грабли конфликтные зарыты?