ユーザー登録やメアド変更がユーザーによって行われる時に、そのアクションを行うユーザーに有効期限付きのトークンを付与したURLが記載されたメールを送信し、ユーザーにはそのURLに飛んでもらって、アクションを完了させてもらうように実装をしました。

その際にメール確認というテーブルを以下の構造で作りました。

user_id	email_address	token	expired_at
1	xyz@example.com	fmkdfakfoafaf	2022:04:04 10:10:00

今実装しようとしているのはパスワード変更機能やパスワードを忘れたときの再設定機能なのですが、既存のテーブルをカラム名を変えて使い回すか、それとも、新たに似た構造のテーブルを作って対応するかで迷っています。

使い回す場合

user_id	comfirmation_item	token	expired_at
1	xyz@example.com	fmkdfakfoafaf	2022:04:04 10:10:00
2	jjfojafafafaJH3gjdk(ハッシュ化されたパスワード)	fmkdfakfoafaf	2022:04:04 10:10:00

email_addressをcomfirmation_itemに変更する

新たに作る場合

既存

user_id	email_address	token	expired_at
1	xyz@example.com	fmkdfakfoafaf	2022:04:04 10:10:00

新規

user_id	password	token	expired_at
1	jjfojafafafaJH3gjdk(ハッシュ化されたパスワード)	fmkdfakfoafaf	2022:04:04 10:10:00

安易に汎用化すると、確認対象項目の型が違う場合やデータ構造が異なるパターンが出てきた時に対応出来ないなと思う一方で、そのときはそれに対応できるテーブルを作ればよいかとも思うのですが、それであれば、最初からそれぞれ専用のテーブルを作れば良さそうとも思います。ただ、その場合、テーブルを細々と作ってテーブルの数を増やして良いものなのかも、バックエンドの経験がほとんどなくて今勉強兼ねてウェブアプリづくりに挑戦してる自分には判断が出来ません。

ちなみに現状、ユーザー登録時、メアド変更時と、パスワード変更時、パスワード再設定時くらいしか、トークン付与したURLを記載したメールを送る予定はありません。

上記で記したような使い回すパターンはアンチパターンだったりしますか？

用途特化のテーブルをふやす方針で行く場合、テーブル数が増えることでなにか弊害ってうまれるのでしょうか？