複数主キーとfind_byでのアップデートどちらが適しているでしょうか

Question

困っていることを単純化した例として以下の内容のCSVがあります。日付はuniqueカラムです。

日付,来場者,
2020/1/1,1000,
2020/1/2,2000,
2020/1/3,3000,
2020/1/4,4000,

以下の操作はActiveRecordの標準機能からの実装を前提としています。

こちらのデータを以下のテーブルのレコードに作成する際、

examples(
    id INT(11) AUTO_INCREMENT NOT NULL, 
    date DATE NOT NULL ,
    visitors INT(11) NOT NULL,
    PRIMARY KEY (id)
);

配列によるinsertはできますが、仮にupdateを行いたくなった時に、このCSVにはIDがないため一件一件find_byを実行しupdateをするしかないと思います。

一方で、id,dateを複合主キーあるいはdateをidにしてしまい、そのままdateを指定してしまえばbulk updateが可能かと思っていますが、他のmigrationの設定やassociationの指定が複雑になってしまい、foreign_keyを複数保持したり、BIGINT以外の型を設定したりといったデメリットがあると思います。

# idはアソシエーションの為残すことを検討している
examples(
    id INT(11) AUTO_INCREMENT NOT NULL, 
    date DATE NOT NULL PRIMARY KEY,
    visitors INT(11) NOT NULL,
    PRIMARY KEY (id)
);

実際、後者の実装を試してみたのですが、アプリケーション側の実装が経緯を知らないと複雑に見えてしまい、どちらも一長一短があり、是非皆さまのご意見を聞かせていただけないかと思い、質問します。聞きたいことは二点です。

• どちらの実装が良いと思いますか？
• これら以外の実装で良いと思われる実装はありますか？

以上よろしくお願い申し上げます。

Answer 1

primaryとは別に、dateをユニークインデックスにして、用途で使い分ける。

[Rails] [RDB] キー・複合キーをきちんと利用する

Comments

[退会済みユーザー]

ありがとうございます。
ちょうど同じような手法に関して、情報を集めてたところで、実際の私のケースでもユニークインデックスを複合カラムで利用するのがよさそうでしたので、ベストアンサーとさせていただきます。

Answer 2

id,dateを複合主キー

少なくとも、この選択は適切ではありません。「複合主キー」は、含まれる列のどれか1つが違えば別に登録できますので、「同じ日付」や「同じid」のものが登録できてしまい、いたずらに事態を複雑化させるだけです。

Comments

[退会済みユーザー]

ありがとうございます。
確かにそうですね。
日付をユニークにしないといけないので、id使えないですね。
質問を更新します。
ちょっと単純化し過ぎてるのですが、実際はこのテーブルがポリモーフィック関連とhas_manyの関連を持っていて、複合主キーの実装では毎回指定が必要なことがネックになるので、前者の実装の方がいいのではないかなと思っています。