RDBで認証のためのユーザーテーブルを分ける設計がある。
ところが、フレームワークに付属の認証テーブル設計を見ると、単一のテーブルで上位管理者と 一般ユーザーを保持している場合もよく見る。
果たして、認証用ユーザーテーブルを分ける意義はあるのか。
分ける流のメリットとしては、
- 誤操作への被害軽減
- 一般ユーザーデータ・アクセスの方がパブリック側だから、最悪アタックされるとしても管理者データを遠ざけるため
- ユーザーデータ検索パフォーマンス
などか？
分けない流のメリットとしては、
- 権限の分だけテーブルを用意するのは権限変更や権限昇格時にユーザーデータをテーブルをまたいで移動することになり、また、権限の分だけテーブルを用意していくのは (設計変更などの) 柔軟性に劣る
- アタックされてデータ取られることがあるならいくらテーブルを分けてようが、その時点で他のデータにもアクセス可能だろうから、アタック耐性として意味がない
などか？
素人なので全く自信ないです。誰に聞けばいいんだろう。漢の人か？
2014/10/21追記
にて、 @tk0miya さんに相談させて頂いた！その時のメモを記載。
- どちらでもあまり変わらないものの…
- 例えばDjangoだとアプリを分けることで2つの認証用ユーザーテーブルを持てる
- その場合、管理者と一般ユーザーで分けるログイン画面／管理画面は分けた方が良いだろう
- ログインフォームを単一にした場合、条件に応じて2テーブルの両方かどちらかを見に行くようにするのは実装が面倒だろう
- ユーザーモデル次第でもある
- ログインユーザーの操作ログもテーブルに保存していく場合は単一のユーザーテーブルじゃないほうが良いかも
- 代理ログイン可能な管理者やユーザーを設ける場合は、ユーザーテーブルを分ける方が実装がラクだったりする (ことがある)
- そのUserは「そもそも何なのか」ということを整理しておくこと。役割なり振る舞いなりを。
- つまり、どのデータにおいても、「データの使われ方」を決めておくこと
- それらに従ってデータ構造と設計が決まっていくので
