20個足らずのマスターデータでもデータベースに保存するべきでしょうか？

Question

id, title, price, slugの4つのフィールドを持つItemクラスがあります。現在自分が扱っている商品は20個足らずで、今後増えても30個はまず超えません。

このような少数のデータであっても、データベースに保存すべきでしょうか？

現在は以下のようにクラスに定義しています。

<?php

class Item
{
    private $id;
    private $title;
    private $price;
    private $slug;

    public function __construct($id, $title, $price, $slug)
    {
        $this->id = $id;
        $this->title = $title;
        $this->price = $price;
        $this->slug = $slug;
    }

    // 以下getter省略
}

class ItemRepository
{
    private $items;

    // id
    const ITEM_A = 1;
    const ITEM_B = 2;
    const ITEM_C = 3;
    // 以下略

    private static $itemList = [
        self::ITEM_A => [
            'title' => 'hoge',
            'price' => 500,
            'slug' => 'fuga',
        ],
        // 以下略
    ];

    public function __construct()
    {
        foreach (self::$itemList as $id => $item) {
            $this->items[$id] = new Item(
                $item['id'], $item['title'], $item['price'], $item['slug']
            );
        }
    }

    public function find($id)
    {
        if (isset($this->items[$id])) {
            return $this->items[$id];
        }
        throw new \InvalidArgumentException('不正なID');
    }

    public function findBySlug($slug) {//省略}
}

また、あわせてお聞きしたいのですが、ItemRepositoryクラスについてもっといい書き方は無いでしょうか？

コンストラクタでItemのインスタンスをセットしてるのがちょっとイケてない気がしています。

よろしくおねがいします。

Answer 1

以下の観点で判断してみるとどうでしょうか？

• どの方法が自分達にとって全体のシステム制御が楽になるのか？
• どの方法が今後の保守や運用といった面が容易になるかどうか？
• 扱っているマスタ定義の置き場所はどこに集約するのが（感覚的に）自然か？

もし、小規模・短期運用であれば、好きなやり方で構わないでしょう。そこまで考えて開発を行う事自体が無駄になるほどコスト的な影響も無いはずです。他にデータベースで扱っているマスタデータが存在し、一貫性を持たせた方が良いと感じるなら、データベース上に置くべきです。データベース以外にシステム設定ファイルなりのマスタ定義に適した場所が存在していれば、それを使うのも手でしょう。

ただし、無理に分離して管理対象を増やすのは、結果的に運用時の調整や手間で痛い目を見るだけなので、定義する場所の集約は適切な規模・範囲で行うべきです。客観的に説明がつくかどうか？も指標として使えるかもしれません。

結果的にはシステムのあるべき姿を捉えると自ずと答えは出るはずです。

蛇足にはなりますが、オブジェクト指向での immutable な概念を齧っていないのであれば軽く齧ると良いでしょう。PHP の言語特徴を考えると少し馴染みにくい概念な気もしますが、定義の見え方そのものが広がると思います。

以上、ご参考になれば幸いです。

Comments

[nemosan]

immutable、勉強してみます

Answer 2

もちろんjsonなりconfig.php等のファイルなりに記載しておく手段もあります。

個人的な意見を言うと、マスター情報は明細と同じデータベースにぶち込んだ方が何かと楽です。
例えば売れ筋商品が欲しい時、RDB(MySQL)にマスタの情報を登録しておけば
一撃で売れ筋商品の一覧が名前や発売日等の付帯情報付きで取り出せます。

別の項目で保存していた場合、
DBに接続して売れ筋商品の情報とマスタIDを元に、
自分でfor文回してマスタの商品名・発売日等の情報を取得する必要があります。

---

追記：ItemRepositoryクラスに関して

素晴らしい！
行クラスとテーブルクラスもちゃんと分かれていますし、こいつ単体でいえば何も言うことはありません。

コンストラクタでItemのインスタンスをセットしてるのがちょっとイケてない気がしています。

現在形で特に問題ないと思います。
まぁ、マスターのデータ更新でプログラムの行数が増減するのはよろしくないので、
外部ファイル化させてさせてうまいことやる設計の方がクールでしょう。

行クラスをもっと活かす

もしfindBySlugの中身がforeachでぶん回してif($item->getSlug() === $slug)とかやってたらNGです。
ItemRepositoryクラスがやるべきことは、個々のItemさんに挙手してもらうことです。
こうすると例外パターンが出現した時にロジックを変更する必要があるのは常にItemとなるので、
問題の切り分けが楽になります。

class Item {
  function slug_is($it) {
    return $this->slug === $it;
  }
}

class ItemRepository {
  function find_by_slug($slug) {
    return array_filter($this->items, function($it) use($slug){return $it->slug_is($slug);});
  }
}

もし更に改良を加える場合

結論から言うと、良い抽象化とマジックメソッドが鍵となるでしょう。
考える方向性としては同じようなテーブル的なものを複数作成する必要が出てきた場合の考慮でしょう。

例えば似たようなまた別のテーブルが必要になったら、
プログラムの設計は統一すべきなので似たような構造で作りますよね？
そうすると、コンストラクタメソッドの引数がバラバラになってまず困るわけですよ。

また、変数名も意識したほうが良いかもしれません。
ItemRepositoryクラスにとってのレコードとはitemsでこれはこれで具体的で二重丸な良い名前ですが、
担当者リストのStafRepositoryクラスが新設されたら同じようにitemsでいきますか？stafsになりますか？

もし私が仮に後輩にレビューして修正指示を出すのであれば、
重複部分を纏めてcommonRepositoryという汎用クラスを作成して、
itemsではなく、recordsという変数名で管理するように指示します。

もしくはカラムの構造が変化した場合の考慮です。
カラムをちょっと弄るだけでも10行単位で変わりますよね？

Comments

[miyabi-sun]

将来を見据えた上で自分ならこうする程度に書きました。

仮にこれを採用したとしても、
今度はItemテーブル1個にどんだけ工数掛けるんねんって問題があるので参考程度でどうぞ。

Answer 3

現状で問題ないならいいんじゃ?
しいていえば、設定ファイル等を別途設けて
それを処理時などに読み込むようにすれば、
ロジックとの分離ができていいかも。