Railsで認証機能を作る際にDeviseを使うことが多いと思います。
DeviseでUserテーブルを作った際に、以下の例のように色々なカラムを追加してUserテーブルが肥大化していくのをよく見かけます。
class DeviseCreateUsers < ActiveRecord::Migration[6.1]
def change
create_table :users do |t|
t.string :first_name, null: false, default: ""
t.string :last_name, null: false, default: ""
t.text :profile,
t.string :telephone,
t.integer :age,
t.integer :role_id,
t.integer :company_id,
t.datetime :deleted_at,
## Database authenticatable
t.string :email, null: false
t.string :encrypted_password, null: false
## Recoverable
t.string :reset_password_token
t.datetime :reset_password_sent_at
## Rememberable
t.datetime :remember_created_at
## Confirmable
t.string :confirmation_token
t.datetime :confirmed_at
t.datetime :confirmation_sent_at
t.string :unconfirmed_email # Only if using reconfirmable
t.timestamps null: false
end
end
end
上記のような実装によって
- Userテーブルが肥大化してコードが色々な責務を持ったUserモデルが出来上がる
- deleted_atによる論理削除を実装したために、Emailをユニークにできなくなる
となってしまっていることがあります。
この記事では私なりに検討した、この問題を防ぐUserテーブルの構成について紹介してみます。
どんな構成か
結論から書きますが、以下のような構成になっています。
この構成のメリットは
- Userテーブルが肥大化しない
- Deviseをカスタマイズする作業が少ない
- Emailはユニークにできる
- 退会したユーザーの情報はとっておくことができる
みたいな点です。
※本実装よりもさらに責務を分割したテーブル構成も実装したこともありました。
が、Deviseのデフォルトから大きくハズレたために、実装が複雑になることもあったので、その点の考慮をいれた実装になっています。
以降この構成で扱っている、各モデルについて詳しく書いていきます。
各Modelについて
Userモデル(User model)
Userモデルはid, created_at, updated_atのみです。
このモデルがあらゆるユーザーに関するテーブルの親になります。
子になることはありません。
このテーブルのレコードは、更新、削除を基本行いません。
ユーザーのSignUp時(=認証情報のレコード作るとき)に一緒に作られる想定です。
# == Schema Information
#
# Table name: users
#
# id :bigint not null, primary key
# created_at :datetime not null
# updated_at :datetime not null
#
class User < ApplicationRecord
# Relations
has_one :user_authenticate
has_one :user_profile
has_many :blogs
has_many :left_users
# Methods
def active?
self.user_authenticate && self.user_profile
end
def already_left?
self.left_users.precent?
end
end
Userの認証情報モデル(UserAuthenticate model)
認証に必要なカラムが存在するテーブルです。
Deviseでつくられたカラムに加えて、上で作ったUserテーブルとのリレーションに使うuser_idカラムがあります。これ以上のカラムの追加は基本しません。
たとえば、名前やプロフィールなどは認証に必要ないので、このテーブルには追加せず、別テーブルにします。
# == Schema Information
#
# Table name: user_authenticates
#
# id :bigint not null, primary key
# user_id :bigint not null
# email :string(255) default(""), not null
# encrypted_password :string(255) default(""), not null
# reset_password_token :string(255)
# reset_password_sent_at :datetime
# remember_created_at :datetime
# confirmation_token :string(255)
# confirmed_at :datetime
# confirmation_sent_at :datetime
# unconfirmed_email :string(255)
# created_at :datetime not null
# updated_at :datetime not null
#
# Indexes
#
# index_user_authenticates_on_confirmation_token (confirmation_token) UNIQUE
# index_user_authenticates_on_email (email) UNIQUE
# index_user_authenticates_on_employee_id (user_id) UNIQUE
# index_user_authenticates_on_reset_password_token (reset_password_token) UNIQUE
#
# Foreign Keys
#
# fk_rails_... (user_id => users.id)
#
class UserAuthenticate < ApplicationRecord
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :validatable, :confirmable
# Relations
belongs_to :user
# Callbacks
## SignUp時、user_idはnilなので、生成を行います。
before_validation :set_user
# Methods
private
def set_user
self.user = User.new if user.nil?
end
end
このテーブルをもっと細かく、EmailやPasswordを別テーブルに分ける案もありますが、そうなるとDeviseを結構カスタマイズする必要が出てきて大変なため、このテーブルを細かく分離することもしていません。
Userプロフィールモデル(UserProfile model)
認証には関係のない、ユーザーの情報を扱うモデルです。
たとえば、名前やプロフィールテキスト、年齢といったカラムが該当します。
また上で作ったUserテーブルとのリレーションに使うuser_idカラムも存在します
これらのカラムが、先ほどDeviseで作った認証テーブルと分離されていることで肥大化が防げています。
# == Schema Information
#
# Table name: user_profiles
#
# id :bigint not null, primary key
# user_id :bigint not null
# name(名前) :string(255) not null
# created_at :datetime not null
# updated_at :datetime not null
#
# Indexes
#
# index_user_profiles_on_user_id (user_id) UNIQUE
#
# Foreign Keys
#
# fk_rails_... (user_id => users.id)
#
class UserProfile < ApplicationRecord
# Relations
belongs_to :user
end
Userが親である子テーブル(Blogs)について(Blog model)
たとえばUserが親である子テーブルを作る場合の例として、Blogsテーブルを例に取ります。
Blogsテーブルのリレーションは、UserProfileやUserAuthenticateとのリレーションではなく、Userモデルとリレーションをさせます。
Userモデルは削除されない想定ですので、Blogsテーブルにあるuser_idはnot null制約を保つことができます。
# == Schema Information
#
# Table name: blogs
#
# id :bigint not null, primary key
# user_id :bigint not null
# title(タイトル) :string(255) not null
# created_at :datetime not null
# updated_at :datetime not null
#
# Indexes
#
# index_blogs_on_user_id (user_id)
#
# Foreign Keys
#
# fk_rails_... (user_id => users.id)
#
class Blog < ApplicationRecord
# Relations
belongs_to :user
end
退会したユーザーを扱うモデル(LeftUser model)
退会したユーザーの情報は、別途このテーブルに保存を行います。
残しておきたい情報をカラムとして追加します。
今回の例では、Emailアドレスとユーザー名は保持しておきます。
このテーブルに保存しておくことで、上で作ったUserProfileやUserAuthenticateのレコードは削除することができます。
UserAuthenticateが削除できるため、Emailの重複を防ぐことが可能になっています。
# == Schema Information
#
# Table name: left_users
#
# id :bigint not null, primary key
# user_id :bigint not null
# email(emailアドレス) :string(255) default(""), not null
# name(ユーザー名) :string(255) default(""), not null
# created_at :datetime not null
# updated_at :datetime not null
#
# Indexes
#
# index_left_users_on_user_id (user_id)
#
# Foreign Keys
#
# fk_rails_... (user_id => users.id)
#
class LeftUser < ApplicationRecord
# Relations
belongs_to :user
end
退会処理の具体例
たとえば、退会処理を実装するときのコード例を示します。
以下のように、left_usersテーブルに必要な情報を作成してuser_profileとuser_authenticateは削除する想定です。
user_authenticate(ユーザーの認証情報)を残しておくと、退会したユーザーとのEmailの重複があり得てしまいます。Emailの重複があり得ると、Uniq制約をつけられないデメリットがあります。
class UserProfiles::LeavesController < ApplicationController
before_action :authenticate_user_authenticate!
def destroy
user_profile = UserProfile.find(params[:user_profile_id])
user = user_profile.user
ActiveRecord::Base.transaction do
LeftUser.create(user: self, email: self.user_authenticate.email, name: self.user_profile.name)
self.user_profile.destroy
self.user_authenticate.destroy
end
reset_session
redirect_to user_profiles_path, notice: "退会完了しました"
rescue => e
redirect_to user_profile_path(id: user_profile.id), alert: "退会に失敗しました"
end
end
おしまい
さて、これで私の考えたDeviseを使ったUserテーブルの解説はおしまいです。
この構成で
- Userテーブルが肥大化しない
- Deviseをカスタマイズする作業が少ない
- Emailはユニークにできる
- 退会したユーザーの情報はとっておくことができる
の条件を満たしたUserモデルの構成ができたと思います。
まだまだブラッシュアップの余地はあるかもですが、ひとまずこちらで終わろうと思います。