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

Question

現在データベース設計を勉強しているものです。
ランサーズのようなCtoCのプラットフォーム系のサービスのテーブル設計を考える上での質問です。

以上のようなテーブルがあるとします。
m_Accounttypeテーブルは文字通りマスターテーブルでアカウント種別を管理するテーブルです。
例えばidが1のものはクリエイター、2のものはクライアントとします。
一方のt_accountTypeはトランザクションテーブルでクリエイターとクライアント共に共通する基本的な顧客情報を管理するテーブルで、外部キーにAccountTypeIdがあるとします。

ここで質問なのですが、クリエイターとクライアントは持ちたい情報が違うと思います。
以下のテーブルは飽くまでも例なので正規化やカード情報そのまま持つなとかが突っ込まないで欲しいのですが、

クライアント側は当然クリエイターに対して金銭を支払わなければならないので、決済手段を持つ意味でカード情報を持ちたいです。クリエイター側は金銭を支払う訳ではないのでカード情報は絶対に必要はないとします。
逆にクリエイター側は自身が何が出来るかを示す為にスキルセットを持ちたいです。しかしクライアント側は依頼側なのでスキルセットの属性は必要ないと思います。
ここで疑問となるのが、このt_Accountをどのように設計すればよいのか、どのようにリレーションを張ればいいのかということです。
一応個人的に考えてみたのですが、、、
①t_accountにskillset属性とcardnumber属性をそのまま入れて、null許容型にする(アカウントタイプによってeditできるようにする)

②null許容をする外部キーを置くべきなのでしょうか？(ClientIdとClientIdにFKを書き忘れました、)

③それともアカウントテーブル自体を完全にクリエイターアカウントテーブルとクライアントアカウントテーブルの2つに分けるべきなのでしょうか？

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

Comments

[wwbQzhMkhhgEmhU]

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

[m.ts10806]

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

Answer 1

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

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

１．同じデータを複数もつ（同じテーブル）
２．クエリエイター、クライアントの差分のみ別テーブルで管理
３．同じデータを複数もつ（別のテーブル）

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

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

Comments

[widget11]

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