Ваша лучшая ставка - сделать одну из двух вещей.Сохраните данные во время транзакции в таблице TRANSACTION или таблице TRANSACTION DETAILS.Это НЕ денормализует.Вам нужны данные по времени, когда они были получены, и оставить их как есть при присоединении к таблице PAYER, которая меняется со временем, что означает, что у вас будут неверные данные.Тот факт, что данные повторяются в нескольких записях, не более значим, чем CA, появится несколько раз в таблице адресов с полем состояния.Вам также следует сохранить идентификатор PAYER, чтобы при необходимости можно было просматривать текущие данные. Это самое простое решение.
Другое решение заключается в добавлении способа поиска данных на основе времени.Это более сложно и должно быть сделано очень осторожно, иначе вы потеряете целостность данных или получите очень странные результаты отчета.Лучше всего, если у вас есть соответствующие таблицы для Payor.Сначала настройте PAYOR, который в основном будет иметь PAYORID и PAYOR DETAILS, которые будут иметь данные на основе времени.Таким образом, вы можете применить ограничение внешнего ключа к PAYOR (чтобы вы могли просматривать текущие данные, если это необходимо), но при этом сохранять несколько записей в таблице PAYORDETAILS, когда происходит изменение адреса или имени и т. Д.Вы также хотели бы, чтобы даты начала и окончания каждой из этих записей и триггера гарантировали, что даты начала / окончания не перекрываются.Например, если у вас есть несколько адресов, это становится еще более сложным, потому что у каждого должен быть тип адреса, активным может быть только один (вы не хотите, чтобы в ваших отчетах показывалось, что вы отправили продукт на три адреса).Все ваши запросы должны учитывать дату начала и окончания, и обычно лучше настроить представление, которое всегда будет отображать только текущую запись.Этот сценарий гораздо сложнее настроить и поддерживать с течением времени, и гораздо более вероятно, что в нем будут ошибки, из-за которых у вас могут не быть правильные данные, связанные с транзакцией.