Допустим, вы отвечаете за благоустройство улиц. Фирма "Пётр и сыновья" подписала с вами договор на то, чтобы покрасить забор по адресу: г. Куйбышев, Староколпакский перулок, 1.
При этом, на уровне базы данных договор будет связан с адресом и с компанией.
Спустя пять лет, Пётр почил. Сыновья Петра продолжают его династию (покраску заборов).
Теперь фирма, с которой был заключён контракт, называется "Борис и Денис". При этом, город Куйбышев начал называться Самара. Теперь, если вы станете искать документ, чтобы получить налоговый вычет, вы вряд ли его найдёте - ваша программа отображает, что фирма "Борис и Денис" по вашему поручению покрасила забор в городе Самаре.
Чтобы избежать подобных казусов, надо хранить в таблице все версии объектов, в том числе устаревшие. В части адресной системы, в этом вам поможет ФИАС, он так и делает (там у каждой записи об адресном объекте хранится идентификатор AOID - это идентификатор конкретной версии объекта, и идентификатор AOGUID - это идентификатор адресного объекта в целом, который не меняется, если объект был переименовал или переподчинён. Аналогичная система, полагаю, существует не только для адресов, но и для свойств когда-либо зарегистрированных юридических лиц.
Foreign Key на языке жестов, изображение с сайта corchaosis.ru
Внешние ключи (Foreign Key) в вашей базе данных должны из документов вести не на объект, а на конкретную, актуальную на момент их создания, версию каждого объекта.
В противном случае ваша банковская система будет назначать клиентам более высокий процент, на основании того что они не живут по адресу, на который указывает штамп в паспорте о прописке. А реально это та же самая улица, она раньше называлась по другому. И всё такое.
