ASP.NET Core Web APIでDB設計するとき、最初に何を意識していますか？
Q&A
.NET
PostgreSQL
Database
WebAPI
現在、ASP.NET Core Web API + PostgreSQLで個人開発をしています。
機能実装は進められるのですが、DB設計になると
などで迷うことが多いです。
経験者の方は、Web APIのDB設計で最初にどんな点を重視していますか？
初心者が意識すべき考え方があれば教えていただきたいです。
個人開発レベルであれば、私は「将来の拡張性」よりも「業務データを正しく表現できているか」を最初に重視しています。
初心者の頃は正規化やテーブル分割ばかり気にしていましたが、後から振り返ると、
を明確にする方が重要でした。
例えば、ユーザーと注文の関係なら、
を先に考え、その後でカラムやインデックスを考えます。
また、個人開発では最初から過度な拡張性を意識しすぎない方が良いと思っています。
「将来こうなるかもしれない」で設計すると複雑になりがちなので、
くらいで十分なことが多いです。
私の場合は、
という順番で進めています。
逆にAPIから先に考えると、後でDB設計に無理が出ることが多い印象です。
第一にビジネス・ドメインを優先します。
何を管理したいのか（概念）を整理します。
以下のように現実世界の「名前（名詞）」からテーブル候補を考えます。
第二にエンティティと関係を定義します。
ER図がアウトプットになることが多いです。
第三にテーブル分割は「役割が違うものは分ける」ことを基準とします。
例えば以下を同じテーブルに入れると変更が大変なことになります。
第四に正規化は「同じ情報を1箇所にだけ持つ」を意識します。
「一つの機能にしか使わない情報」であれば、無理に別テーブルにせず、一つのテーブルにまとめてしまうことも一案です。
第五に物理削除ではなく「論理削除」を最初から考慮します。
Web APIの運用でよく発生する問題が「間違えてデータを消してしまった」というトラブルです。
データを DELETE 文で完全に消す（物理削除）のではなく、削除フラグ項目を用意します。削除時はこのフラグを反転させる「論理削除」を採用することで、誤ってデータが消える危険を減らせます。
@tony_stark
Questioner
This is exactly the kind of mindset I was looking for—thank you. "Decide the concept first, then model entities and relationships, then split by role" gives me an order to think in rather than agonizing over all four concerns at once.
The normalization principle ("the same information lives in only one place") and the note that you don't always need to split into separate tables if the data only serves one function were especially helpful, since I tend to over-split early. And logical deletion is a good call for an API.
ASP.NET Core Web APIでDB設計するとき、最初に何を意識していますか？
「ASP.NET Core Web APIでDB設計」という事情が分かりません。
既存の DB があって、それから Web API を介してデータを提供するという話なら DB 設計は関係ないはずです。
既存の DB とかは存在しなくて、何らかのデータを Web API で提供したいという話なら、EF Code First を利用するという話になりませんか？
