Да зачем спускаться, нужно обыкновенное преобразование в некий обобщённый формат. Туда и обратно.

mayton,

Побить на блоки, не?

mayton,

На блоки по рейнджам значений. Так, чтобы удаление, не сдвигало разбивку. Потом искать оптимальный размер блоков, или некую формулу.

Не по хешу, конечно же.

Вообще, хеш лучше заменить на контрольную сумму.

mayton,

Ну если согласно условиям задачи, можно добавить колонку. Значит стоит добавить суррогатный порядковый ключ.

Возможность поддерживать натуральные и комплексные ключи добавляет разработчикам тех же ORM очень много головной боли. Настолько много, что глядишь в код, интерфейсы и понимаешь, что 60% сложности это поддержка подобных решений.

Или по-другому. Давайте посмотрим на задачу только в контексте суррогатного ключа. Хотя бы так она решается? Давайте по шагам.

Такие ключи подвержены необходимости поддерживать правило ON UPDATE.
Это увеличивает сложность на порядки, так как ключ -- больше никакой не ключ. Извините.

За счёт чего вообще работает тот же Git?
За счёт того, что работает с текстовыми файлами, где у каждого файла есть уникальный путь.
А у каждого файла есть строки, которые расположены строго друг за другом.
И предположение, которое гласит, что в основном, любое изменение не нарушает общий порядок строк.
Именно поэтому в принципе возможно такое понятие, как diff.
Он описывает какие строки изменились, какие строки вставить после каких, а какие удалить.

Если перейти на язык алгебры, то набор данных должен быть

1. строго упорядочен
2. иметь ненатуральную идентификацию

Твоя постановка противоречит этому условию.
Хеши ничего не дают, не порядка, ни идентификации.

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

Чтобы сделать обобщённое решение, должны быть определённые обобщённые условия.
Которых нет от слова совсем.

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

1. Добавляем в каждую реплицируемую таблицу суррогатный ключ, специфичный Repl_ID
2. Добавляем в каждую реплицируемую таблицу отметку времени последнего изменения.

Если 2 невозможно, то задача усложняется.

Создаём таблицу для отслежнивания изменений такой структуры:




Рассматриваем вариант, когда добавление отметки времени последнего изменения невозможно.

Алгоритм простой до безобразия.
Репликатор перебирает все таблицы
Перебирает все строки каждой таблицы
Считает CRC от всех полей (кроме Repl_ID)

Теперь репликатор может легко выбрать новые, изменившиеся и удалённые строки.
И обновить табличку Replica.

Почему не хеш? Потому что хеш медленный и нафиг он тут не упал.
Он медленный.
Достаточно выбрать подходящую CRC функцию с хорошим распределением.

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

И да. Если идти от способа вычисления хеша от ключа, то задача -- не выполнимая. Потому что натуральные ключи могут меняться. Для репликатора изменение ключа, это удаление + создание. А на мастере это ON UPDATE CASCADE.

Репликатор тупо встанет раком со своими космическими алгоритмами.

Сложные решения -- плохо, уродливо и некрасиво. Простые решения -- хорошо, и красиво.