ユーザテーブル設計の話

アプリケーションを一から実装していて、ユーザ情報を設計する際にうまくなかったと思う点があった。それについて考察をまとめる。

状況としては開発途中で、あるエンティティをどのユーザが更新したかということを保持したくなり、ユーザ種別ごとに分けてしまったためどう拡張するか戸惑ってしまった。

仕様

対象となっているアプリケーションはちょっと特殊で3種類の異なるユーザが存在している。またそれぞれの種類のユーザが持つ属性が異なる。

今回採用した設計

ユーザの種類ごとにテーブルを分ける手法を採用した。

メリット

  • 各ユーザ種別ごとにテーブルが異なるので、シンプルに誤りが少ない。例えば直接テーブルを参照するときなどにも誤った種類のユーザを参照しているというようなことは考えにくい
  • ユーザ数が膨大な量になった際にも特に何もしなくてもデータ自体がテーブルごとに分散される
  • 例えばエンティティの更新イベントをエンティティの属性として実装せずに、イベントストリームとして捉えて実装すれば今ある懸念は払拭される

 

理想な設計

ユーザごとにテーブルを分ける必要はなかったのではないかと思う。

メリット

  • ユーザドメインの実装を簡略化できる。
  • 実装としても基底ユーザを継承した各種ユーザクラスを実装すればよく、テーブル構造に依存せずにオブジェクト指向の実装はシンプルにできる
  • 例えばあるエンティティに対する更新ユーザを記録する updatedBy などの属性を設けた際に、シンプルになる。
  • ユーザ種別ごとにシャーディングを実装すればデータ分散も可能
  • あとからユーザ種別が増えた際にも対応コストが比較して少ない

 

少し異なるユーザ同士が同じテーブルに存在することを毛嫌いしすぎたと思う。おそらくそれによるデメリットよりもその他のメリットを捨ててしまったことのほうが大きい。

が、現状の状態を拡張するのであれば各種ユーザの画面上での操作をイベントという形で記録すれば良さそうであるというふうにも感じ、昨今の流れでは割と自然なのではないかとも思っている。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください