Я использую собственную схему, хотя далеко не всем она может понравиться. Однако, именно эта схема устраняет основной недостаток Merge-репликации - несогласованность транзакций. На каждую таблицу у меня прицеплен Instead-триггер, который заменяет операции удаления и изменения на операции добавления. По справочникам используется сразу три идентификатора.
1. Идентификатор записи справочника (наиболее глобальный).
2. Идентификатор модификации записи справочника, относящийся к конкретному учетному периоду. На оси учетного времени может буть несколько записей с одним ID1, но разными ID2. В специальном служебном поле указывается "период жизни" данной редакции записи на учетном периоде. С помощью этого приема добиваюсь того, что при переименовании контрагента "Рога и копыта" в "Копыта и рога" с 01/04/2001 эти две записи воспринимаются как одна запись справочника, но при распечатке документов в разных учетных периодах в них выводятся разные наименования одного и того же контрагента. (Так же все работает при смене сотрудником фамилии, изменении юридических реквизитов и т.п.)
3. Идентификатор RowGUID записи таблицы. Используется при репликации и как идентификатор редакции записи на оси календарного (а не учетного) времени. Записи с одинаковыми ID1 и ID2 могут иметь разные ID3, если какой-либо пользователь производил модификацию или удаление записей. В системных полях фиксируется автор модификации (кто создал запись, модифицировал, удалил), имя компьютера в сети, с которого произведена операция, имя удаленного сервера, на котором зарегистрирован пользователь, дата и время модификации и специальный флаг логического удаления (физическая модификация и удаление не производятся!).
В таблице кроме актуальных записей находятся и не актуальные - история модификации записей (или журнал, кому как нравится). Может, кто-то скажет, что это снижает производительность по сравнению с журналом в отдельной таблице, однако в SQL2K материализованные представления решают проблему производительности. Конфликты репликации напрочь отсутствуют (и в принципе возникнуть не могут). Актуальной считается запись с наиболее поздним временем модификации/создания.
Документы и другие справочники ссылаются только на ID1.
Убиваются сразу два зайца - журнализация и проблемы репликации. Правда, возни много...