Обычно создаётся примерно такая схема БД:
1.
2.
контрагент (id number primary key, название varchar2( 2000 ), инн number, ...)
документ (id number primary key, контрагент_id references контрагент, ...);
В результает встаёт проблема - при изменении данных контрагента изменяются и данные всех связанных с ним документов, а это как правило не то что нам нужно. Тогда встаёт вопрос хранения истории контрагента.
Вариантов может быть много, лично мне больше нравится следующий.
Если рассмотреть эту задачу с позиции построения DWH, то таблица "документ" по сути является таблицей фактов, тогда как таблица "контрагент", похожа на таблицу измерений, но в силу своей изменчивости не может быть таковой. Напрашивается решение - завести таблицу контрагентов с теми данными, которые фигурируют или должны фигурировать в документе. По структуре такая таблица может содержать все поля из таблицы "контрагент", плюс идентифицирующее поле конкретной версии данных. В итоге имеем такую схему:
1.
2.
3.
4.
контрагент (id number primary key, название varchar2( 2000 ), инн number, ...)
контрагент_история (id number primary key, контрагент_id number /* без references на контрагент, поскольку запись из таблицы контрагент может быть удалена */, название varchar2( 2000 ), инн number, ...)
документ (id number primary key, контрагент_id references контрагент_история, ...);
Кто то скажет, а почему бы не слить таблицы контрагент и контрагент_история. Это вполне возможно, но тогда придётся вводить статусы актуальности данных контрагента, отслеживать права на изменение записей, которые могли поучаствовать в документах и т.п. В добавок, в оперативной таблице "контрагент" постепенно будут накапливаться исторические данные, которые уже не нужны для текущих операций, что может негативно сказаться на производительности системы.
