Добрый день народ. Сто лет ни куда не писал.

Реализовал я тут репликацию между базами данный в течении 1 года полет нормальный. Смысл был такой. Минимум затрат и как можно проще. Целью были справочники и настройки пользовательских мест. Добавление информации и изменение работает на ура. Причем весь обмен работает на EXECUTE BLOCK.

Схема работы моей репликации проста есть 4 базы 1 из них основная.
Сначала информация копируется из основной базы в удаленную, только потом обратно.
Если есть изменения в основной базе они рассылаются в удаленные.
Если были загружены изменения они тоже рассылаются в удаленные.
На уровне справочников и настроечных таблиц (профилей/ролей, доступа к данным и т.п.) получаем полный дубляж баз. Красота, изменил доступ к программе пользователю выполнил обмен и ни куда бегать не надо за тридевять земель.

Но есть узкое место это удаление данных. Мы пока решили, что удалять ничего не будем просто помечаем "*" в начале названия и все. В настройках это не прокатило и в нескольких таблицах пришлось добавить толе DEL типа удалено. (То есть дали доступ на изменение параметров пользователю, а потом забрали, то есть удалили строку из списка кто имеет право к параметру). Но геморроя от таких полей добавляется столько что становится тошно.
Геморрой следующий при выводе в списках/отчетах приходится учитывать что строка удалена. (Блин в DBF было хорошо в первом байте данных "*" была если строка удалена и такие строки игнорировались)
Вот сижу и думаю может сделать еще таблицу в которой в порядке удаления были удалены данный (ИД+Название таблицы). В этом случае можно реально просто удалить не важно в какой из баз.
Тут просто другая проблема наклевывается, нужно для каждой базы выполнить действие удаления, а значит нужно одну строку удаления размножить в главной базе с флагом "выполнено" для этой базы данных и только после того как во всех базах будет "ОК". То считать строку удаленной. Но если нельзя удалять то восстановить из базы которая не дала удалить данные.

Что думаете или как вы это реализуете?

Я вот к этому и склоняюсь т.к. следить за записями с полем DEL это будет слишком. Если б сервер поддерживал такую работу было б супер просто сбросил флаги и записи снова доступны. Хотя тут тоже есть подводный камень чистка таких строк. По этому мне больше нравиться таблица с удаленными ИД. Причем судя по разговору с DY можно вообще автоматизировать процесс 1 одинаковое тело триггера на все удаляющие триггеры. Т.к. можно узнать имя таблицы в которой идет удаление автоматом из триггера.

Dimitry SibiryakovЕвгений Болтиксудя по разговору с DY можно вообще автоматизировать процесс 1
одинаковое тело триггера на все удаляющие триггеры. Т.к. можно узнать имя таблицы в
которой идет удаление автоматом из триггера.
А вот отсюда поподробнее, пожалуйста. Один триггер на несколько таблиц? Имя таблицы -
ладно, а как достать значение первичного ключа?


Не 1 триггер а ОДНО ТЕЛО. Я описываю макрос и этот макрос в тело триггера ложу. При генерации базы данных тела сами создаются. Хотя учитываю то что у меня собственный генератор баз данных, то я могу решить это на уровне ядра генератора.

КЛЮЧ. Элементарно батенька этим у меня BLOCK и занимается из методанных вытягивает. Но я не советую идти только этим путем, не всегда первичный ключ главный. Я тут репу последний раз с этим сломал пришлось дать возможность указать вручную, если не указан ключ, то автоматом. (к примеру в таблице есть 1 уникальных составной индекс и он главный т.к. нужно чтобы одно из составляющих поле было NULL. Жаль примари этого недопускает)
Для репликации в любом случае приходится описывать логику следования данных по приоритету и особенностям хранения данных:
таблица такая
потом такая
потом такая но не надо копировать такие то поля (если их автоматом обновляет триггер к примеру)
потом такая но к ней привязаны такие таблицы

Dimitry SibiryakovЕвгений БолтикДля репликации в любом случае приходится описывать логику следования
данных по приоритету и особенностям хранения данных:
Нет, если проводить операции в целевой БД в точности в той же последовательности в которой
они производились в исходной.


1.Прийдется формировать лог что не очень то нужно. Хотя и оправдано. Но вихриватые изменения из соседних баз сделают свое дело и мы получим оплиуху с неточными данными.
2.Не получиться без уточнения, что копировать нельзя ;)
если вторичная таблица делает изменения в первичной
begin
if (updating or deleting) then
update D009_SCODEINFO set
SUMMA_DEBT = SUMMA_DEBT
- iif(old.IDOperation in (0, 2), old.SUMMA, 0)
+ iif(old.IDOperation in (1, 3, 5, 7, 9), old.SUMMA, 0)
where D009_SCODEINFO_ID = old.D009_SCODEINFO_ID;
if (updating or inserting) then
update D009_SCODEINFO set
SUMMA_DEBT = SUMMA_DEBT
+ iif(new.IDOperation in (0, 2), new.SUMMA, 0)
- iif(new.IDOperation in (1, 3, 5, 7, 9), new.SUMMA, 0)
where D009_SCODEINFO_ID = new.D009_SCODEINFO_ID;
end
в первичную таблицу можно получать но только не суммируемые
я уже так впоролся сумма по карте была меньше чем по акту сверок с клиентом. Оказалось что данные были перекрыты старой информацией из другой базы ;)
Репликация настолько тонкая вещь что можно впороться даже на ровном месте к примеру с первичным ключом. Я буквально этим на неделе и занимался. Зато теперь составные ключи работают без проблем. Раньше их избегал для репликации.
Все эти проблемы всплывают т.к. нельзя точно сказать из какой именно базы надо заливать данные(могло не быть связи и залили в той последовательности какая была, а вечером до залили из той базы которая была недоступна)
Если слить лог при 100% работе всех баз и сделать сточной последовательностью не уверен что все пройдет гладко если много логики на триггерах. О сложности построения моих баз ходили легенды (хвала нашим разработчикам они прислушивались). В каких то случаях это оправдано, но какие то моменты приходится теперь учитывать из за той же репликации. К примеру деревья я раньше всегда хранил на одно таблице (В репликации просто зная это я хитрю работая в несколько проходов). Теперь уже делаю на 2. Хотя и неудобно.

Dimitry SibiryakovЕвгений БолтикРепликация настолько тонкая вещь что можно впороться даже на ровном
месте
Не преувеличивайте. Да, есть в ней неочевидные моменты. И да, криво спроектированная БД
будет криво реплицироваться. Но в остальном это довольно примитивная вещь.


По поводу кривизны базы не надо тут (все считать кривым что написано писателем считать нельзя, разные цели). Как сказал "artemana" не хватает некоторых моментов для полного счастья и я согласен. Вот когда деревья делаются на 2 таблицах вот это кривизна навяленная нам архитектурой базы. Причем каждое разбиение на таблицы грозит падением производительности при запросах. Если этого у вас не случается значит сложность запросов не высока. Или вы добавляете некую избыточность в данные, что мне приходится делать постоянно (отдельная тема попробую на днях изложить мысли). По сути не хватает отложенной проверки целостности вливаемы данных. Но тут понадобятся дополнительные инструменты управления происходящим. Не бывает так чтобы всех устроить одним методом.

Dimitry SibiryakovЕвгений БолтикРепликация настолько тонкая вещь что можно впороться даже на ровном
месте
Не преувеличивайте. Да, есть в ней неочевидные моменты. И да, криво спроектированная БД
будет криво реплицироваться. Но в остальном это довольно примитивная вещь.


да еще не получится потому, что есть дополнительная логика к примеру продажи товара с прихода(вроде обычно называют партия) нельзя списать боль чем получено. Пришло 10 залили в удаленки. Кто то продал 10 в главной поменяли на 9. И на тебе гранату.
Так что без описания определённых действий программе нельзя сделать перенос. Если чисто справочники то тут фигня война пошло бы.

Dimitry SibiryakovЕвгений БолтикИ на тебе гранату.
Это не проблема репликации, это проблема бизнес-логики.


Вот мы с тобой и имеем то что надо описывать ход действий. Я может не совсем понятно сначала выразился.

Dimitry SibiryakovЕвгений Болтикпродажи товара с прихода(вроде обычно называют партия) нельзя списать
боль чем получено. Пришло 10 залили в удаленки. Кто то продал 10 в главной поменяли на
9.
Исключим из картины компьютеры. Пришла в центральный офис накладная на 10 штук товара.
Разослали почтой по филиалам сообщение "есть 10 штук к продаже". В филиале продали 10
штук. Теперь в центральном офисе кто-то берёт ручку и на накладной зачёркивает 10 и
вписывает 9. "И на тебе гранату."
Вопрос: какие правила можно прописать на почте, чтобы такого не случилось?


В моей почте это документ излишки. делается автоматом. а товароведы потом разруливают.

Гаджимурадов РустамЕвгений Болтик> В моей почте это документ излишки

Излишки или недостатки?



Именно излишки т.к. продали же, а значит было. Недостача может быть только по факту ревизии т.к. именно нету/не было.

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

После разговора с вами меня натолкнуло на мысль,
а ведь я методанные уже который год четко все прописываю перед обновлением.
Единственное что не в методанных это данные базы формы ввода, печатные формы, модули т.п.
Почесав тыковку прикрутил это все простым(ну почти простым) взмахом руки.
И на тебе репликация помогла обновлять данные в базах.
Раньше обновление до новой версии на маленьких
(ну очень маленьких базах была от 1 до 3 минут), на больших до 1.5 часа.
Новое с использованием репликации до 30 секунд у клиентов может максимум 1 минута будет).
Век живи век учись.

hz2Он скрипты обновления метаданных в пакет репликации включил, имхо. У меня такое уже лет 5 работает.

Да ты прав. Молодец. С полпинка понял.

У меня репликации раньше не было. Я другим занимался. Тем более с 2002 года где то база автоматом обновлялась и как то не надо было быстрей. А тут раз репликация была написана, я подумал, а почему бы не попробовать. Получилось.

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

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