kakakikikeke's Tips

データベース設計の根幹を理解する：トランザクションの基礎知識 「トランザクション」という言葉は、データベースやシステム開発の現場で頻繁に使われますが、具体的な仕組みやなぜそれが必要なのかを深く理解している方は少ないかもしれません。本記事では、データの一貫性と信頼性を保証するための最も重要な概念である、トランザクションについて基礎から解説します。 平たく言えば、データベースにおける「複数の処理のまとまり」のことです。この単位で一連の作業を定義し、「全部成功するか、何もかも失敗する」という保証を与えるのがトランザクションの役割なのです。 なぜトランザクションが必要なのか？（データの整合性の問題） 日常的なシステムの操作を想像してみてください。例えば、Aさんの口座からBさんの口座へ1万円を送金する場合を考えます。 処理１：Aさんの残高から1万円を減らす 処理２：Bさんの残高に1万円を加える この二つの処理は、「セット」で実行される必要があります。もし、処理１（引き落とし）が成功したものの、ネットワーク障害などにより処理２（追加）の途中で失敗してしまったらどうなるでしょうか？ Aさんのお金は消え、Bさんには入らないという、恐ろしいデータ矛盾が発生してしまいます。このような予期せぬ失敗からデータを守り、「絶対に矛盾しない状態」に保つために登場するのがトランザクションです。 トランザクションを支える「ACID特性」とは データベースのシステムが、どのような状況でもデータの整合性を保てることを保証する、理論的な要件群があります。それが「ACID特性」です。この4つの要素を理解することが、トランザクションの本質を捉える鍵となります。 A - Atomicity（原子性） トランザクションがひとまとまりの不可分な単位であること。たとえ途中でエラーが発生しても、実行された処理はすべて巻き戻され（ロールバック）、まるで何も起こらなかったかのように元の状態に戻ります。 C - Consistency（一貫性） トランザクションが開始されても終了するまで、データベースの制約やルール（例：残高はマイナスであってはならない）を常に満たす状態に保たれること。不正なデータが入ることを防ぎます。 ...

DBの正規化をやりすぎた結果 DBの正規化をやりすぎた結果 データベース設計において、正規化は非常に重要な概念です。データの重複を防ぎ、データの整合性を保つために、テーブル間の関係性を整理し、各テーブルのデータ量が最小限になるように設計していく必要があります。しかし、正規化を追求しすぎると、かえってシステム全体のパフォーマンスを低下させる可能性があります。実際に、私が経験したケースを以下に報告します。 問題の発生と状況 あるeコマースサイトのプロジェクトで、私はデータベースの設計を担当していました。当初の要件は、商品の登録、顧客情報の管理、注文の処理、在庫管理など、一般的なeコマースサイトに必要な機能をサポートすることでした。顧客からの要望に応じて、より詳細な顧客情報（住所、電話番号、メールアドレス、趣味、家族構成など）を記録できるように、テーブル構造をかなり複雑に正規化しました。顧客テーブル、商品テーブル、注文テーブル、在庫テーブル、顧客詳細テーブル…　それぞれのテーブルが細分化され、テーブル間の関連付けも非常に複雑になりました。 パフォーマンスの低下 しかし、リリース後、徐々にパフォーマンスの問題が発生し始めました。特に、顧客情報の検索や、特定の顧客の注文履歴の取得が遅くなっていることが顕著でした。パフォーマンス監視ツールを使って分析した結果、データベースのクエリが非常に多くのテーブルを結合していることが原因であることが判明しました。顧客の情報を取得するために、顧客テーブル、顧客詳細テーブル、注文テーブル、商品テーブル…と、テーブルを繋げていくクエリが実行されるため、JOIN操作のオーバーヘッドが非常に大きくなっていました。 原因の分析 原因を詳しく分析した結果、正規化を追求するあまり、顧客テーブルと顧客詳細テーブルが過剰に分割されてしまったことが判明しました。顧客テーブルには、顧客ID、氏名、住所などの基本的な情報のみが格納され、顧客詳細テーブルには、電話番号、メールアドレス、趣味などの詳細情報が格納されていたため、これらのテーブルを結合して顧客情報を取得するクエリが非常に複雑で非効率的でした。JOIN操作が何度も繰り返されることで、データベースの負荷が著しく増加し、パフォーマンスが低下していました。 対策と結果 ...