Ruby on Railsで、ECサイトのスクレイピング処理を実装しております。

・ECサイトの情報を保持するStoreテーブル
・過去の情報を保持するHistoryテーブル

があり、

Store
- id(主キー)
- name
- site_id

History
- site_id(主キー)
- ranking

といったテーブル構成になっております。

スクレイピングをしているため、Historyテーブルの主キーはECサイト側で保持しているsite_idが主キーになります。

そのため、私が管理しているRailsアプリケーションのStoreのidを外部キーにして
参照することができません。

尚、Storeテーブルの主キーをsite_idにすれば解決しますが、今回はそうしたくありません

そうしたくない理由は、StoreテーブルのリレーションがHistoryだけでなく、UserやServiceテーブルとリレーションがあり、idが主キーであった時からの改修が発生するのと、仮に、site_idを主キーとした場合、
Storeを画面から登録するときに、site_idを間違えて登録してしまった時のバグに気が付きにくくなることを懸念しております。

今回やりたいこと

Storeの主キーはidのまま、site_idを外部キーに渡して、Historyテーブルを参照するようにしたいです。

次のような実装方法を試してみたものの、ダメで、主キーである、site_idを元にhisotryテーブルを参照してしまいます・・・

本件に対する解決案がありましたら、アドバイスを頂きたく存じます。

よろしくお願いします。

class Store < ActiveRecord::Base
  has_many :histories, foreign_key: 'site_id', class_name: 'History', dependent: :destroy
end

class History < ActiveRecord::Base
  belongs_to :store, foreign_key: 'site_id', class_name: 'Store'
end

尚、こういうことも試しましたが、
こうすると、既存のstoreのidがsite_idに書き換わってしまうため、断念しました。

class Store < ActiveRecord::Base
  self.primary_key = :site_id
end

また、広くご意見賜りたいためこちらにも質問させていただいております。
https://teratail.com/questions/42905

追記

StoreとHistoryの関係は
1対多を想定しております。

また、Storeテーブルの主キーをsite‌_idにすれば解決しますという風に記述しましたが、
エラーがなく、レコードがとれましたが、正しくとれたかどうかはちょっとわかりません（色々といじっていたため、そのことが直接の原因出ない可能性があります。）

ややこしく申し訳ありません。