Каскадное удаление записей ... своими руками.

Разбираясь с синхронизацией баз столкнулся с проблемой такого рода: не знаю как реализовать удаление записей.

Проблема вот в чём:
1) разные пользователи базы имеют доступ к разным наборам таблиц и работают они удалённо друг от друга без доступа к сети. Соответственно у каждого будет свой кусок общей базы. И их приходится синхронизировать. При этом заливать каждому полную копию базы глупо, вредно и опасно.
2) не все пользователи имеют право на удаление записей, по этому они могут только пометить запись на удаление.
3) в рабочей базе 57 таблиц и их количество будет увеличиваться, поскольку меняется структура производства и методы информирования клиентов, соответственно приходится заводить новые таблицы.
4) центральная база будет связана с разнородными БД / СУБД (связана дополнительно с базой сайта - MySQL, возможно позже будет ещё с чем-нибудь)

Посему нельзя использовать Access-овское каскадное удаление записей.
Для каскадного удаления можно было бы написать набор запросов, в которых перечислить порядок удаления записей..., но не хотелось привязываться к определённой структуре базы. Если привязываться к "текущему состоянию" базы, придется каждый раз перепиливать структуру запросов и под каждого пользователя. Это ж представляете сколько дополнительной работы. Не говоря уже о возможных ошибках. Хотелось бы решить этот вопрос по надёжней. Лучше я сейчас напишу несколько дополнительных листов кода, чем в дальнейшем отгребу полную котомку геморроя.
Нужен универсальный механизм, который по сигналу из центральной базы будет обходить все связанные таблицы и удалять данные связанные с требуемой записью начиная с самой "дальней" таблицы.

Aeliot,

Я бы первым делом во все таблицы добавил поле "КодЮзера" и при каждом чихе его обновлял, что касается пометки на удаление, то можно единожды нарисовать модуль, который будет удалять все эти записи из всех таблиц всех ваших переносимых БД. Как к ним обращаться вы знаете, как перебирать таблицы в бд наверное тоже в курсе, правда здесь лучше сделать таблицу с названиями таблиц снизу вверх, от многие к одному, чтобы корректно удалить запись. Только вот интересно как они помечают на удаление, могут на стороне мноиге пометить, а на стороне один нет? Или же у вас удаляются всегда записи только на стороне многие? Тогда вообще никаких проблем нет и быть не может.

alvk
Я бы первым делом во все таблицы добавил поле "КодЮзера" и при каждом чихе его обновлял

я прикрутил триггер Бенедикта, несколько переделав его. Конкретного юзера пока не отслеживает, но мысль возьму на заметку.

alvk
Только вот интересно как они помечают на удаление

создано поле для этих дел

alvk
могут на стороне мноиге пометить, а на стороне один нет?

могут и на стороне один. Причем в таблице, связанной ещё с двадцатью, которые, в свою очередь, связаны с другими таблицами.

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

сделал таблицу в которой прописал связи: "название таблицы один", "название ключевого поля", "название таблицы многие", "название поля содержащего внешний ключ"

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

Уже этим занимаюсь. Хотелось бы, чтоб подсказали более оптимальный вариант обхода таблиц.

Прикрепляю файл с таблицами. Это не "рабочая база", а "экспериментальная" -- чтоб разобраться с технологией.

Aeliot

1. Нет счетчиков. Естественные ключи хороши для пользователя. Для системы счетчик трудно заменить.
2. Все операции по изменению данных надо делать в транзакции. Будет гарантия целостности данных
3. Для каждой операции из таблицы tblSincRelations очень желательно иметь набор записей в специальной таблице, где записаны имена (или SQL-выражения) запросов, необходимых для совершения транзакции. В процедуре, в блоке транзакции, сканируется выборка из спец.таблицы для заданного поля заданой таблицы и выполняются запросы, записанные в спец.таблице.

Aeliot,

Спасибо за файл, может через годик гляну, когда Акцесс 2012 выйдет

alvk,
вот в *.mdb

Aeliot,

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

Всем спасибо. Разобрался.
Вот выкладываю работу.
Делал в тестовой базе и реализовывал только обход таблиц в текущей.
Меня интересовал именно алгоритм обхода связанных таблиц.
Допилить на распределенную базу не составит большого труда.

alvk
У вас реально что-то зверское с кодами, ваши счета должны быть отдельными полями, а не выполнять функцию первичного ключа таблицы

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