DB設計

statusカラムと題に載せているが、複数の定数を選択肢として持つような所謂enum型のカラムに関することを述べていく（statusという名で定義されることが多いような気がしたので） そのようなstatus系のカラムは楽で便利が故によく提案されると思うのだが、追加する前にちょっと整理・考慮しておきたい点がある。 因みにアンチstatusカラムという訳ではなく、メリデメをしっかり議論されていればOKな立ち位置なのである そのカラムを使ってどのようなSQLを構成する予定か まずはstatusカラムを使ってどのようなSQLを書く予定があげてみよう。 意外にもそのカラム追加によってSQLパフォーマンス…

重要な考え方 情報とデータ データ 単なる事実の値。 これを永続化して蓄えるのがRDBの目的。 情報 データから生み出される、意味や目的のあるもの。 SQLで出力する。 更新(UPDATEとDELETE)は複雑さを生む そもそも集合論的に更新はない。 更新にはテーブルを見るだけではわからない複雑なルールを伴うため、極力更新を避けるようにDB設計すべき。 この価値観は、不足しているエンティティや属性の発見にもつながる。更新で対応していたことが、実はエンティティや属性が不足していたことが原因ということが発見されうるということ。 更新がなければデータが失われることはない。 更新を許す = 履歴や遷移…

下書き。 URLがほしいので一旦公開。

下書き。 URLがほしいので一旦公開。 サマリデータ 集計用のカラムを追加し、そこに保存する。 (達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ p.149-152) いつ使うのか 集計処理のパフォーマンスを向上させる必要がある時。 サマリデータを追加する = 推移的関数従属が生まれる ということなので、サマリデータは必要最小限にする。 選択条件の冗長化 同一のカラムを複数のテーブルに持たせる。 (達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ p.153-156) 参考 達人に学ぶDB設計 徹底指南書 初級者で終わりたくないあなたへ

新卒2年目ですががっつりDB設計をすることがあり、その際に思ったことなどをまとめておく。 3層スキーマを意識しておけばよかった 特に設計の内容が変わるわけではないのだが、どこまでやればDB設計を完了とみなしていいかがあまりわかっていなかった。今までの現場経験的なところで各カラムのデータ構造まで決定していれば大丈夫だろう。という曖昧な感覚でDB設計を終わらせてしまっていた。 今思えば3層スキーマに従って、外部設計の画面仕様書作成中は、外部スキーマを決定してるようなものだなー。ER図で論理設計をしているときは概念スキーマを決めているんだなー。じゃああとは内部スキーマの決定だけ必要だからそこまでやれ…

概要 普段の業務でデータベース設計を行っているので基本的なことはわかっているつもりですが、知識の再確認のため、データベース設計の入門書で有名な「達人に学ぶDB設計 徹底指南書」を読んだ感想です。 良かったところ 複雑なデータベース設計の概念をわかりやすい説明がされており、初心者でも理解しやすい内容となっていること 正規化等のデータベース設計のベストプラクティスを学ぶことができたこと 当たり前のようにやっている正規化について、その名前（第o正規形など）を知ることができたこと 悪かったところ 主キーに「可能な限り自然キーを使う」 主キーに「可能な限り自然キーを使う」という点が引っかかり、「それは状…

はじめに はじめまして、2022年3月中旬にコミューン株式会社に入社した西山です。 普段はフロントエンドのエンジニアとして開発業務に携わっています。 この記事では、私がERモデルを使ったDBのデータモデリング（以下、データ設計）を行う際、特に意識していることを3つ紹介します。 尚、具体的にユースケースからエンティティを抽出する方法や、チューニングなどの物理設計については触れません。