С точки зрения архитектуры данных, я предлагаю решить вашу заявленную проблему

... когда заказ будет размещен, он будет { {1}} всегда может ссылаться на адрес пользователя , который использовался во время размещения заказа .

... вы просто копируете адрес человека в модель Заказа. Элементы будут в модели OrderItem. Я бы переформулировал проблему следующим образом: «Заказ происходит в определенный момент времени. OrderHeader включает в себя все соответствующие данные в этот момент времени».

Это ненормально?

Нет, потому что OrderHeader представляет собой момент времени, а не текущая «правда».

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

- Придерживайтесь решения, которое решает настоящую проблему, а не возможные проблемы - кому-нибудь нужна история изменений пользователя? Или вам просто нужны заголовки заказа, чтобы отразить реальность самого заказа?

Добавлено: Обратите внимание, что вам нужно знать , на какой адрес в конечном итоге был отправлен заказ / счет. Вы не хотите смотреть на старый заказ и видеть текущий адрес пользователя, вы хотите увидеть адрес, который заказ использовал при отправке заказа. См. Мой комментарий ниже, чтобы узнать больше об этом.

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

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

Я думаю, это будет так просто:

Users:
  id
  name
  address_id

UserAddresses:
  id
  user_id
  street
  country
  previous_address_id

Orders
  id
  user_id #to get the users name
  user_address_id #to get the users address

Затем, когда пользователь меняет свой адрес, вы выполняете своего рода «логическое удаление» на старом data, создав новый UserAddress и установив поле "previous_address_id" как указатель на старые данные. Это устраняет необходимость в вашей таблице карты и создает своего рода связанный список . Таким образом, всякий раз, когда размещается заказ, вы связываете его с определенным UserAddress, который гарантированно никогда не изменится.

Еще одним преимуществом этого является то, что он позволяет вам отслеживать изменения адреса пользователей, что-то вроде рудиментарного регистратора.

Вы ищете плагин acts_as_audited. Он предоставляет таблицу аудитов и модель для использования вместо вашей карты.

Чтобы установить его, запустите миграцию и добавьте следующее в модель адресов пользователей.

class UserAddress < ActiveRecord::Base
  belongs_to :user
  acts_as_audited
end

После того, как вы настроите это, все, что вам нужно сделать, это определить метод адреса в заказе. Что-то вроде этого:

class Order < ActiveRecord::Base
   belongs_to :user
   attr_reader :address

   def address
     @address ||= user.user_address.revision_at(updated_at)
   end
end

И вы сможете получить доступ к адресу пользователя в момент завершения заказа с помощью @order.address

revision_at - это метод, добавленный в модель аудита с помощью acts_as_audited. Он берет временную метку и восстанавливает модель в том виде, в котором она была в этот момент времени. Я полагаю, что он собирает ревизию из аудитов, проведенных в этой конкретной модели до указанного времени. Поэтому не имеет значения, совпадает ли updated_at в заказе с точным временем.