ブログ

区分（ここではgroup）の値で取得したものを配列（あるいはオブジェクト）でもち、その値の中から必要なデータ（ここではname）を他のテーブルに紐づける、と言ったイメージ。

実際、classification_table をどう利用するかというと、以下の user_table のようにもたせていました。
（さらに user_table 以外のテーブルでも classification_table が参照されるような設計になってしまっていましたが、今回は省略します）

user_table.category_id を設定する際は classification_table.group = categories のものから設定する、という（私の中では）よくありそうな設計でした。（user_table.contact_id, user_table. area_id でも同様）

DB設計に関する疑問

ある日、PJメンバーからとある疑問をいただきました。

『このclassificationテーブルのデータって、データベースに格納して持つ必要あるんでしょうか👀』

テーブルで持つ以外だったらどうしましょうか🤔と相談させていただき、
”各モデルに定数で持たせれば良いのでは？💡”
と、例えば以下のようにしてはいかがでしょうか。とアドバイスをいただきました🙇‍♀️

// 定義の例
public const CATEGORY_LABEL = [
    self::DAI => '大区分',
    self::CHU => '中区分',
    self::SHOU => '小区分'
];

確かに、マスタデータとしてシステム側でのCRUDを準備するほどではないデータだからと、わざわざなんでもかんでもDBに持たせる必要はそもそもありませんでした。

Laravelではアクセサや前回のブログでも紹介したscopeを利用し、以下のように定義・取得することができます💡

// 取得するときの例
public function getCategoryLabelAttribute(): string
{
    return self::CATEGORY_LABEL[$this->category];
}

public function scopeCategoryDAI($query)
{
    return $query->where(function ($builder) {
        $builder->orWhere('categories', '=', self::DAI)
    });
}

なぜこんな設計をしてしまったのか

さらに、なぜテーブルにわざわざ持たせてたんだろうか？🤔というところにまで話は及びます。

その理由はこのブログの前半に書いた『DBからデータを取得する際も素のSQLを直接文字列で書く』という、自分の中での勝手な常識となってしまっていた、まさにヨロシクナイ習慣 （= アンチパターン）でした😨
（Laravelで言うところの）Modelを意識していなかったため、直接SQLそのものをガリガリ書いても違和感を感じていなかったのです。

フレームワークがちゃんと準備してくれています

そもそも、現在携わっている開発で使用しているLaravelでは、素のSQLを書くことは基本的にありません。（前回のブログ参照）
Laravelにはとても便利な ORM（Eloquent） が組み込まれています✨
Eloquentはデータベースとモデルを対応づける機能です。
ちゃんとEloquentモデルオブジェクトで返してくれてデータ型も担保されている上に、その後のデータの取り扱いを便利にしてくれるクエリビルダも使うことができます👍

しかし、今回のようなごった煮テーブルとなってしまった classification_table でEloquentを使うことの旨味はおそらくほぼなさそうです🤷‍♀️
しかもなんのデータが入ってるのかもぱっと見では分かりづらく、メンテナンス性も悪くなりそうです🙅‍♀️
（なんなら格納する値の型が異なった場合、 classification_table では格納することができずまた似たような構造のごった煮テーブルを作るようなことになりかねない😫）

今回の出来事で得た教訓

1. 何が入っているかぱっと見ではわからないようなテーブルは作るべからず
2. 何でもかんでもデータをDBに格納すればいいというものではない
3. フレームワークの仕様に準拠したDB設計を意識すること

そんなこんなで久しぶりに アンチパターン本 と向き合おうと思いました・・・・😵‍💫