質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

90.12%

CtoCのプラットフォーム系のサービスを作成する際のテーブル設計のヒントを頂きたいです

解決済

回答 1

投稿

  • 評価
  • クリップ 1
  • VIEW 346

widget11

score 167

現在データベース設計を勉強しているものです。
ランサーズのようなCtoCのプラットフォーム系のサービスのテーブル設計を考える上での質問です。
イメージ説明
以上のようなテーブルがあるとします。
m_Accounttypeテーブルは文字通りマスターテーブルでアカウント種別を管理するテーブルです。
例えばidが1のものはクリエイター、2のものはクライアントとします。
一方のt_accountTypeはトランザクションテーブルでクリエイターとクライアント共に共通する基本的な顧客情報を管理するテーブルで、外部キーにAccountTypeIdがあるとします。

ここで質問なのですが、クリエイターとクライアントは持ちたい情報が違うと思います。
以下のテーブルは飽くまでも例なので正規化やカード情報そのまま持つなとかが突っ込まないで欲しいのですが、
イメージ説明
クライアント側は当然クリエイターに対して金銭を支払わなければならないので、決済手段を持つ意味でカード情報を持ちたいです。クリエイター側は金銭を支払う訳ではないのでカード情報は絶対に必要はないとします。
逆にクリエイター側は自身が何が出来るかを示す為にスキルセットを持ちたいです。しかしクライアント側は依頼側なのでスキルセットの属性は必要ないと思います。
ここで疑問となるのが、このt_Accountをどのように設計すればよいのか、どのようにリレーションを張ればいいのかということです。
一応個人的に考えてみたのですが、、、
①t_accountにskillset属性とcardnumber属性をそのまま入れて、null許容型にする(アカウントタイプによってeditできるようにする)
イメージ説明
②null許容をする外部キーを置くべきなのでしょうか?(ClientIdとClientIdにFKを書き忘れました、)
イメージ説明
③それともアカウントテーブル自体を完全にクリエイターアカウントテーブルとクライアントアカウントテーブルの2つに分けるべきなのでしょうか?
イメージ説明

個人的に留意していただきたい点は、 1人のクライアントは多数のクリエイターに対して、ランサーズのように仕事をポストできる、また特定のクリエイターに対して個人的に仕事を依頼出来るという点で設計をしたいです。
データベース設計って非常に難しいですね。。。長くなってしまいましたがよろしくお願い致します。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • wwbQzhMkhhgEmhU

    2019/01/25 06:13

    難しくてよくわかっていませんが、RDBMSの場合、テーブルが多くてJOINが多くても時間がかかるし、テーブルサイズが大きくてもハッシュやフルスキャン時の時間がかかります。どれがいいかはDBとデータ量次第かと思います。とりあえずID系は慣習として文字列にしてるところが多いです。理由は知りません。

    キャンセル

  • m.ts10806

    2019/01/25 11:39

    wwbQzhMkhhgEmhUさん
    id系は普通、数値型ですよ。pkになることがほとんどなので検索や並べかえなどの観点から文字列は選択されません。
    商品コードなど英字から始まるものですら、別個に数値型のidを持たせたりprefix列を別でもたせることも少なくないです。

    キャンセル

回答 1

checkベストアンサー

0

基本的には、好みや要件なので、お好きにどうぞという回答になると思いますが。
考慮点として

クリエイターが、クライアントとしても登録する場合を考えてみると
1~3は、以下のようなデータの管理方法になります。

1.同じデータを複数もつ(同じテーブル)
2.クエリエイター、クライアントの差分のみ別テーブルで管理
3.同じデータを複数もつ(別のテーブル)

勉強中ということなので、まずは作ってみてもいいんじゃないでしょうか。
t_accountとt_client、t_creatorのリレーションも、きっと勘違いされているようですし。
※1つのカード番号が複数のアカウントにひもづくとは考えずらい

あと、荒いエンティティで業務?が、管理できるか検討(概要設計)した方がよいかと思います。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2019/01/28 02:13

    分かりやすい回答をありがとうございます。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 90.12%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる