質問: 現在データベース設計を勉強しているものです。 ランサーズのようなCtoCのプラットフォーム系のサービスのテーブル設計を考える上での質問です。 ![イメージ説明](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/cf0f35367a16c896ed627a4a2e88c49e.png) 以上のようなテーブルがあるとします。 m_Accounttypeテーブルは文字通りマスターテーブルでアカウント種別を管理するテーブルです。 例えば**idが1のものはクリエイター、2のものはクライアント**とします。 一方のt_accountTypeはトランザクションテーブルでクリエイターとクライアント共に共通する基本的な顧客情報を管理するテーブルで、外部キーにAccountTypeIdがあるとします。 ここで質問なのですが、クリエイターとクライアントは持ちたい情報が違うと思います。 以下のテーブルは飽くまでも例なので正規化やカード情報そのまま持つなとかが突っ込まないで欲しいのですが、 ![イメージ説明](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/078406478b9631656c5c77a5f9c89325.png) クライアント側は当然クリエイターに対して金銭を支払わなければならないので、決済手段を持つ意味でカード情報を持ちたいです。クリエイター側は金銭を支払う訳ではないのでカード情報は絶対に必要はないとします。 逆にクリエイター側は自身が何が出来るかを示す為にスキルセットを持ちたいです。しかしクライアント側は依頼側なのでスキルセットの属性は必要ないと思います。 ここで疑問となるのが、このt_Accountをどのように設計すればよいのか、どのようにリレーションを張ればいいのかということです。 一応個人的に考えてみたのですが、、、 1t_accountにskillset属性とcardnumber属性をそのまま入れて、null許容型にする(アカウントタイプによってeditできるようにする) ![イメージ説明](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/8f2b7dfad3d041cdf96faba152e603b1.png) 2null許容をする外部キーを置くべきなのでしょうか?(ClientIdとClientIdにFKを書き忘れました、) ![イメージ説明](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/c74f2ea6c91087f2354a870ee21374d9.png) 3それともアカウントテーブル自体を完全にクリエイターアカウントテーブルとクライアントアカウントテーブルの2つに分けるべきなのでしょうか? ![イメージ説明](https://teratail-v2.storage.googleapis.com/uploads/contributed_images/a05943f299d3320eed2c7c98999bbaa4.png) 個人的に留意していただきたい点は、 1人のクライアントは多数のクリエイターに対して、ランサーズのように仕事をポストできる、また特定のクリエイターに対して個人的に仕事を依頼出来るという点で設計をしたいです。 データベース設計って非常に難しいですね。。。長くなってしまいましたがよろしくお願い致します。
回答: 基本的には、好みや要件なので、お好きにどうぞという回答になると思いますが。 考慮点として クリエイターが、クライアントとしても登録する場合を考えてみると 1~3は、以下のようなデータの管理方法になります。 1.同じデータを複数もつ(同じテーブル) 2.クエリエイター、クライアントの差分のみ別テーブルで管理 3.同じデータを複数もつ(別のテーブル) 勉強中ということなので、まずは作ってみてもいいんじゃないでしょうか。 t_accountとt_client、t_creatorのリレーションも、きっと勘違いされているようですし。 ※1つのカード番号が複数のアカウントにひもづくとは考えずらい あと、荒いエンティティで業務?が、管理できるか検討(概要設計)した方がよいかと思います。