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

Прежде всего - о локальном справочнике. Понятно, что в нем должны быть все интересные Вам поля. Основной вопрос - с версионностью этого справочника.

1. Как минимум, из него не должны удаляться записи. Если требуется, можно сделать логическое удаление (признак "запись удалена").

2. Довольно часто требуется помнить, какие именно атрибуты действовали на момент той или иной операции (и у Вас стоит такая задача). Здесь можно:

2а. Сделать именно исторический справочник (SCD2). То есть поля: ид_записи, ид_покупателя, действует_с, действует_по, прочие атрибуты покупателя. При каждом изменении данных новая версия кладется в справочник с новым ид_записи, новыми атрибутами и тем же ид_покупателя. Данные в таблицах ссылаются на ид_записи.

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

Далее, что касается загрузки. Я бы сделал таблицу "Операции загрузки внешних данных", куда складывал бы каждый вызов соответствующей операции с попутными данными - кто, когда, как назывался файл итп. Для загружаемых данных я сделал бы таблицу с необходимыми полями, привязанную внешним ключом к операции загрузки (по любой строке можно сказать, когда она загружалась). Кроме того, я бы привязал эту таблицу к ид_записи внутреннего справочника (смысл ключа - эта запись внешнего справочника породила в эту запись локального). Загрузка шла бы следующим образом: INSERT новых строк в таблицу внешнего справочника, далее сравнение с актуальными данными локального справочника, порождение согласованной версии данных и простановка связок.

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

Отдельно - может быть ситуация, когда желательно принимать решение по тем или иным коллизиям. Например, если у одного gcode сменились все поля - это изменение того же клиента или удаление старого клиента плюс появление нового под тем же номером. Это непростой режим, я делал его так:

Создал таблицу "коллизий" - описание проблемы, ссылки на данные, поле "код решения".

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

Если во время проверки обнаруживались неразрешенные коллизии, дальнейшая загрузка срубалась.

Пользователь в интерфейсе смотрел данные и принимал решение по каждой коллизии - проставлял тот или иной вариант ее решения.

Повторный запуск загрузки снова запускал проверку, которая находила коллизию, находила запись о коллизии с проставленным вариантом решения и не взводила флага "обнаружены нерешенные коллизии".

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

фигасеЧто такое SCD2?
Типовое название описанной далее структуры данных, если угодно, паттерн. http://www.1keydata.com/datawarehousing/scd-type-2.html

Ну, там много чем не пахнет - скажем, устанавливать соответствие этих двух записей (то, что это две версии одной записи) придется по "Кристине", а установить, какая из них раньше, какая - позже вообще невозможно (если не постулировать возрастание ID как критерий возраста). Это простенькое наглядное изложение. Поищите другие материалы - найдете и дата_по, и стержневой ID, и не только.

фигасеНет, подождите, две даты + ключ - однако очень странная комбинация, я бы сказал, избыточно-противоречивая.
Хм. Боюсь, даже чтобы доказать избыточность, Вам придется принять два постулата о содержащихся в справочнике данных, причем один из них (об отсутствии логического удаления) не слишком часто встречается на практике.

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

фигасеСледовательно, на его ид_записи где-то есть ссылка. По этой ссылке выбирается запись. Правильно?
Безусловно. И я даже сказал, где именно. В задачах, связанных с бумажными документами, довольно часто стоит задача восстановления реквизитов на нужную дату, чаще всего дату документа. Поэтому в документах чаще всего стоит пробивать ид_записи.

фигасеКак вы решаете такие проблемы:
1. Эта запись неактуальна по временному интервалу.
Боюсь, не понял вопроса. Запись может оказаться неактуальной только если процедура создания документа проставила кривую ссылку. Что, конечно, проблема и решается отладкой.

фигасеИли это не справочник, тогда вы по ид_покупателя ищите актуальную по времени
Задача искать "актуальную по времени" в таких случаях практически не возникает, хотя, как Вы понимаете, легко решается. Обычно требуется искать "актуальную прямо сейчас", что обычно решается либо дополнительным флагом, либо условием дата_по is null.

фигасе2. Отсутствует актуальная запись на данный момент времени (разрыв)
В ряде случаев это нормальное состояние - например, сотрудник может уволиться и затем вновь устроиться на работу. В данном случае этого не возникнет в силу логики загрузки - каждая очередная запись закрывает предыдущую и сама ложится как текущая актуальная. Бывают более интересные случаи - например, как-то мне пришлось писать процедуры, которые позволяли грузить исторические данные в произвольном порядке (то есть ситуация - люди нашли старый файл, закачали и данные в системе стали "еще более правильными", уточнили соответствующее место в истории изменений).

фигасе3. Несколько записей актуальны в данный момент времени (пересечение)
Опять же в первую очередь вопрос построения - довольно трудно представить, как такое может возникнуть даже без соответствующих проверок целостности.

Ну а реализовать соответствующую проверку более чем нетрудно - один простой селект.