こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
以下、イベントページから引用です。
DB設計においてスケールを考えずに安易な名称やテーブル構造で作成してしまい、後から後悔した経験は無いでしょうか？小さいプロジェクトだからとログ用テーブルを参照する処理を書いたり、逆に正規化し過ぎて開発効率が落ちた。そんな後悔をしないために、様々なアンチパターンについて知る必要があると言えるでしょう。今回はプロジェクトにおけるデータベース設計の基本や運用事例も交えてどのようなアンチパターンがあるのかをテーマにお話します。
会の様子
DB設計の基本を外すとどうなるのか？
最初は長谷川さんから発表がありました。
正規化をしない
最初の基本外しとして、DBで正規化を行わないとどうなるのか？という話がありました。
パフォーマンスの問題や無駄なカラムの発生などが困ることとして紹介されました。
自由なテーブル
次の基本外しとして、テーブルを自由に作ってしまうこと(=主キー制約や外部キー制約などをしないこと)が挙げられていました。
制約をつけないと、期待されるビジネスロジックとの乖離やデータの質の向上が起こるというお話でした。
過程の抹消
最後の基本外しとして、常に最新の情報だけを保持することが挙げられていました。
過程がない状態だと、ドメインによっては後々遡及が必要になった際に集計ができなくなってしまう(or大変になってしまう)という話が出ていました。
履歴管理テーブル設計におけるアンチパターン
続いて横田さんの方から、履歴管理テーブルを作成するタイミングにおけるアンチパターンの話がありました。
過度な正規化
最初に、過度な正規化が挙げられました。
正規化を行いすぎると、join対象のカラムが1テーブルだけ変わってしまった場合などに履歴が改ざんされてしまうというお話でした。
変更履歴を1テーブルで管理
続いて、1テーブルで現在の状態(最新情報)と過去履歴を管理するパターンが挙げられました。
このパターンを採用してしまうと、サブクエリを作る必要が出てきてクエリが重くなってしまったり、1つのデータを更新する必要がある際に、過去のデータも含めてすべて更新する必要が出てきてしまうといった問題点が起こるというお話でした。
質疑応答
発表の後は質疑応答がありました。以下、主な質問の内容と回答を常体で記載していきます。
すでに稼働しているアプリケーションのテーブルを変更するときに工夫していることはあるか？
- 影響範囲調査をダブルチェックし、開発メンバーに共有する
- 小さな変更を積み重ねる
- 必ずしも理想的なテーブル設計に変更しない(開発が入る頻度などをもとに変更するかの判断を行う)
履歴をどこまで保存するといいのか？
- 開発しているプロダクトやドメインによるが、発表で例として挙げた注文管理であるならば商品名と価格の変更は残しておいた方が良いと思っている
会全体を通した感想
イベント参加時に想定していたよりも初歩的な内容だったので、内容から得られる学びという点ではそこまでなかったのですが、説明の仕方やプレゼンの構成といった部分は参考になる部分が多くありました。
