DB設計で難しいところは
「ビジネスルール・将来のための柔軟性」と
「アプリ・DB構造の複雑性」のトレードオフの判断

例えば会員ランクに開始終了日時をもたせてるのは
「会員XXXはY月Z日からはゴールド会員」のような未来予約ができるようにするため思うんだけど
こういう種類の柔軟性が特典・加入条件・年会費に必要かどうかを
ビジネス要求と実装の両面から判断しないといけない

仮にランクになるための条件が増えたりした場合に
その要件が決まってからアプリだけでなくDBを改修したのでも十分だと判断したなら
別テーブルで行持ちにせずに同じテーブルで列持ちにしたのでもOK