データベースとして最適な構造はどちらなのでしょうか？

Question

データベースとして最適な構造はどちらなのでしょうか？

データベース初学者です。最近railsで勉強のためにスマホアプリ用apiを作っています。
その中で、ある２つのテーブルを作成しており、
Aテーブル
・hoge
・hogehoge
・hogehogehoge
・hogehogehogehoge
・Aにしかない要素

Bテーブル
・hoge
・hogehoge
・hogehogehoge
・hogehogehogehoge
・Bにしかない要素1
・Bにしかない要素2

といった構成になっています。(hogeは共通要素)
AとBは共通要素が多いですが、APIとして利用する際に同時に呼び出すことはありません.

わからない点・疑問

こういった場合、今の状態のままAとBのままテーブルを分けて利用したほうが良いのか、それとも、
AとBを合わせたテーブルC

Cテーブル
・bool:AであるかBであるか
・hoge
・hogehoge
・hogehogehoge
・hogehogehogehoge
・Aにしかない要素(Bの時はnull)
・Bにしかない要素1(Aの時はnull)
・Bにしかない要素2(Aの時はnull)

のようにテーブルは一つにまとめ、APIを呼び出す際にクエリで分けたほうが良いのか、速度やコードの美しさの観点からどちらが良いのか教えていただきたいです。

Comments

[phper.k]

データベース設計は、何を作りたいのか、運用フローはどうするのかという前提があって、その前提に合わせて設計するものです。
「何を作りたいのか」「どのように運用するのか」という前提を共有した上で、質問した方が適切な回答がつくと思います。

[m.ts10806]

速度は自身で試したらわかりますし（実行計画は取ること）、コードについては比較対象がないので答えようがなく、また個人の感覚やプロジェクトのルールにもよります。

[m.ts10806]

PHPとの関連性も不明です。
前提とするDBとバージョンにもよります。どれくらいのデータ量をどれくらいのスパンで処理しどれくらいのパフォーマンスなら許容するのか
仮のものが多すぎると他者には要件伝わりません

Answer 1

AテーブルとBテーブルを連動して例えばUNIONしたりして検索する可能性があるなら
最初からCテーブルを作った方が効率的かもしれませんね
検索条件が別ならわざわざ合体させる必要は無いと思います

Comments

[kousukehiraki]

他の方々含め、前提条件の曖昧な質問にすぐにお答えいただきありがとうございました。
皆様のご意見を参考にして勉強したいと思います。