20個足らずのマスターデータでもデータベースに保存するべきでしょうか？
解決済
回答 3
投稿
- 評価
- クリップ 0
- VIEW 915
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のインスタンスをセットしてるのがちょっとイケてない気がしています。
よろしくおねがいします。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+5
以下の観点で判断してみるとどうでしょうか？
- どの方法が自分達にとって全体のシステム制御が楽になるのか？
- どの方法が今後の保守や運用といった面が容易になるかどうか？
- 扱っているマスタ定義の置き場所はどこに集約するのが（感覚的に）自然か？
もし、小規模・短期運用であれば、好きなやり方で構わないでしょう。そこまで考えて開発を行う事自体が無駄になるほどコスト的な影響も無いはずです。他にデータベースで扱っているマスタデータが存在し、一貫性を持たせた方が良いと感じるなら、データベース上に置くべきです。データベース以外にシステム設定ファイルなりのマスタ定義に適した場所が存在していれば、それを使うのも手でしょう。
ただし、無理に分離して管理対象を増やすのは、結果的に運用時の調整や手間で痛い目を見るだけなので、定義する場所の集約は適切な規模・範囲で行うべきです。客観的に説明がつくかどうか？も指標として使えるかもしれません。
結果的にはシステムのあるべき姿を捉えると自ずと答えは出るはずです。
蛇足にはなりますが、オブジェクト指向での immutable な概念を齧っていないのであれば軽く齧ると良いでしょう。PHP の言語特徴を考えると少し馴染みにくい概念な気もしますが、定義の見え方そのものが広がると思います。
以上、ご参考になれば幸いです。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+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行単位で変わりますよね？
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+1
現状で問題ないならいいんじゃ?
しいていえば、設定ファイル等を別途設けて
それを処理時などに読み込むようにすれば、
ロジックとの分離ができていいかも。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
2016/04/04 10:59