データベースの設計について

Question

前提条件

ユーザ毎に提案を管理できるウェブアプリケーションの新規開発案件
があるとします。
このデータベースの内容は以下のような定義をしたとします。

データベースの構造

• users ユーザテーブル

id、username等・・・

• articles 提案書

id、user_id、title、content等・・・

このアプリケーションは将来的な拡張性を考慮して開発するようにとの事ですが
将来的に何をするのか？具体的なビジョンはなく開発者自身で推測の上
考えなくてはいけない状況だとします。

考えた末、ユーザの機能として既存の提案書以外に日報やメモなどこれに類似するような
機能は追加されても対応できるようにと考えるようになりました。

仮に日報機能を追加する事になった場合、対応する方法として主に以下の２つの方法が上がります。

• 方法１

新たにreportsテーブルを作成する

• 方法２

articlesテーブルにcategoryカラムを追加し、この値がproposalの場合は提案、
reportの場合は日報である切り分けを行う事で共用して使えるようにする。

聞きたい事

どれが正解だとは決められませんが、皆さんはどちらの方法を選択されるか理由も含めて教えて欲しいです。

補足

articlesテーブルに限らず、何かしら親のテーブルに対するステータスを管理する子テーブルなど
同じようなテーブルが機能追加の度に増える事に対し、保守・拡張性について考えた場合、理由もなくこれが正しいのか疑問に思う時があります。

時々、Wordpressのwp_optionsのようにステータスや設定に関する情報は１テーブルで管理した方が、拡張性が良いのでは・・・と思う時もあります。

皆さんのご意見をお聞かせ願います。

Comments

[m.ts10806]

WordPress直接関係ないのでしたらタグはずした方が良いかと

Answer 1

将来的に何をするのか？具体的なビジョンはなく開発者自身で推測の上

考えなくてはいけない

要求定義もされていない仕様書なんて、最小限の機能だけ盛り込めばいいんです
追加の仕様が必要になった場合別途追加費用をかっぱぐのがSEの仕事

Answer 2

ベンチャー企業ばかりで働いている者です。拡張性は最低限で良いと思います。
自分なら方法1も方法2も取らないです。

最低限の実装をして、実物を見てもらって、追加要望を聞くと思います。
簡単にできるものなら、相手が何を欲しているのか予測する前に、作っちゃった方が喜ばれることが多かったです。

簡単にできないものなら、簡単にできるところだけ作って見せて、少しづつ要件を詰めていきます。

それもできないなら、耳と目を閉じ、口をつぐんで作ります。
開発する人間が欲しいのではなく、手を動かす機械が欲しいのだろうと思うので。

Answer 3

個人的には、方法１新たにreportsテーブルを作成する、が良いです。
方法２をお勧めしない理由を述べます。

方法２

articlesテーブルにcategoryカラムを追加し、この値がproposalの場合は提案、
reportの場合は日報である切り分けを行う事で共用して使えるようにする。

categoryカラムはCategoriesテーブルに存在するレコード（ proposal , report ）を外部キーとして参照するように設定したとしましょう。これで、articlesテーブルで提案書も日報も格納できるようになりました。

しかし、提案書と日報でそれぞれ異なるカラムを持つ場合、 各カラムがそれぞれどのarticlesの種類に紐づくのかのメタデータを、articlesテーブルは保持することができません。

新たな種類を追加する際に新たなカラムを追加しなければいけない場合は、その都度（本番稼働しているDBの）スキーマの変更する必要も出てきます。

方法2は俗に シングルテーブル継承 と呼びます。シングルテーブル継承が適切なのは、種類の数とその種類固有のカラムの数が少ない場合です。

もし、提案書と日報しか種類として保持しないのであれば、方法2でも問題ないかもしれません。しかし今後の拡張性を考えると方法1がベターではないでしょうか。