QA@IT
«回答へ戻る

回答を投稿

返信が遅くなりすみません。

タグはdatabaseですが、内容から見るに DBの設計というよりはORMフレームワークを前提にしたモデル設計の話の様なので その方向で回答します。
垂直分割自体は悪ではないですが(この構造ならそこまでやるなら正規化したほうが良いとは思いますが)、N+1問題は気を付けたほうが良いでしょう。関連が1箇所に集約されているのでEager loadingするにも毎度全て収集するのかといったバランスも考えないとダメかもしれません。

あとはstatusの全てが外にあったほうが良いのか(itemに常に必要とされるstatusはないのか)といった部分は整理されたほうがいいと思います。

また、最初の回答にも書きましたが誰にとって良い設計なのかも考えておくといいと思います。
モデルだけを扱うだけで良い(DBは意識しない)から、追加のSQLを気にしなくて良いから、DB構造が綺麗になるからか、インデックスのコスト、インポート容易性など
いくつかの視点があると思いますが、全てをクリアできない時にどれを優先するのかは考えておくといいと思います。

コード上の見渡し(ミスの軽減)を目的としているという記述は見受けられましたが、モデル直接扱わずに間に薄い層を設けたり、テストコードで解決する手もあるでしょう。
DB保守の面で言えば後述しますが図にもいくつか疑問があります。

ORMフレームワークを利用するにしても概念設計・論理設計は簡単にでも行っておいた方が良いとは思います。
単に分割するだけにならないように注意して設計してください。
視点が違えば優劣のつけ方も変わってくると思います。どちらが目的に適しているかで選択されると良いでしょう。


以下は追加の回答で提示していただいた図を見ての疑問点です。
ちょっと重箱の隅をつくような話なので、本題と関係なさそうであれば特に回答はなくて問題ありません。

主に2番目、3番目の図の話です。

  • 〜_hoge 列がなぜ各statusに移動していないのかがわからない(型としてキーでもなさそうなのでstatusに移動すべきではないか)
  • item_status_type1s テーブルには列がそのまま移植されているようであり、そうなれば 1:1のままではないか。 これは列を行にするつもりだったということでしょうか。
  • item_status_type4s テーブルは列は1つでは?(元のテーブルが _cN を持たないようなので)
  • item_status_typeNs テーブルに列 item_statuses_idがあるが関連としては逆では?(双方向に関連させるのでしょうか)

図にしてくれたのはありがたかったですが、部分的に疑問に思うことがあったためいくつか混んらんしてしまいました。

また、テーブル構成に置いて 3番目の図におけるitem_statuses_idは idと論理的に同じはずであり、手動で設計した場合は発生しない列です。
テーブルを管理する上では冗長な情報であるのでDBだけを見た場合のためにどこかに明示しておいたほうが良いでしょう。
3番目の図は話の流れでは itemsからitem_statusesが生まれており、それを知っていればitems(主)からstatus(従)を取りに行くのが自然に思いますが、
一方で双方向に関連をつけ艇た場合は item_statusesからitemsを分離したという見方もでき、 item_statusesを主としてitemsにアクセスすることができます。
これが許容できるのか(スタイルの一貫性などで問題とならないか)も考えたほうが良いでしょう。

返信が遅くなりすみません。

タグはdatabaseですが、内容から見るに DBの設計というよりはORMフレームワークを前提にしたモデル設計の話の様なので その方向で回答します。
垂直分割自体は悪ではないですが(この構造ならそこまでやるなら正規化したほうが良いとは思いますが)、N+1問題は気を付けたほうが良いでしょう。関連が1箇所に集約されているのでEager loadingするにも毎度全て収集するのかといったバランスも考えないとダメかもしれません。

あとはstatusの全てが外にあったほうが良いのか(itemに常に必要とされるstatusはないのか)といった部分は整理されたほうがいいと思います。

また、最初の回答にも書きましたが誰にとって良い設計なのかも考えておくといいと思います。
モデルだけを扱うだけで良い(DBは意識しない)から、追加のSQLを気にしなくて良いから、DB構造が綺麗になるからか、インデックスのコスト、インポート容易性など
いくつかの視点があると思いますが、全てをクリアできない時にどれを優先するのかは考えておくといいと思います。

コード上の見渡し(ミスの軽減)を目的としているという記述は見受けられましたが、モデル直接扱わずに間に薄い層を設けたり、テストコードで解決する手もあるでしょう。
DB保守の面で言えば後述しますが図にもいくつか疑問があります。

ORMフレームワークを利用するにしても概念設計・論理設計は簡単にでも行っておいた方が良いとは思います。
単に分割するだけにならないように注意して設計してください。
視点が違えば優劣のつけ方も変わってくると思います。どちらが目的に適しているかで選択されると良いでしょう。

---

以下は追加の回答で提示していただいた図を見ての疑問点です。
ちょっと重箱の隅をつくような話なので、本題と関係なさそうであれば特に回答はなくて問題ありません。

主に2番目、3番目の図の話です。

* 〜_hoge 列がなぜ各statusに移動していないのかがわからない(型としてキーでもなさそうなのでstatusに移動すべきではないか)
* item_status_type1s テーブルには列がそのまま移植されているようであり、そうなれば 1:1のままではないか。
これは列を行にするつもりだったということでしょうか。
* item_status_type4s テーブルは列は1つでは?(元のテーブルが _cN を持たないようなので)
* item_status_typeNs テーブルに列 item_statuses_idがあるが関連としては逆では?(双方向に関連させるのでしょうか)

図にしてくれたのはありがたかったですが、部分的に疑問に思うことがあったためいくつか混んらんしてしまいました。

また、テーブル構成に置いて 3番目の図におけるitem_statuses_idは idと論理的に同じはずであり、手動で設計した場合は発生しない列です。
テーブルを管理する上では冗長な情報であるのでDBだけを見た場合のためにどこかに明示しておいたほうが良いでしょう。
3番目の図は話の流れでは itemsからitem_statusesが生まれており、それを知っていればitems(主)からstatus(従)を取りに行くのが自然に思いますが、
一方で双方向に関連をつけ艇た場合は item_statusesからitemsを分離したという見方もでき、 item_statusesを主としてitemsにアクセスすることができます。
これが許容できるのか(スタイルの一貫性などで問題とならないか)も考えたほうが良いでしょう。