23章ディプロマティック・イミュニティ(外交特権) #SQLアンチパターン

23.1 目的: ベストプラクティスを採用する

ソフトウェアエンジニアリングのベストプラクティス

ベストプラクティスを怠るとプロジェクトは失敗に向けて進みだす

アプリケーション開発のルールはデータベース開発には当てはまらない
=> 「ディプロマティック・イミュニティ(外交特権)」

そう考えられる理由は

以下のような兆候がある

すべてのコードにドキュメントやテストを書くのは大変ですよね？

何度も使うコードに対してはベストプラクティスを適用しましょう
その場限りのコードであれば、そうしなくてもいいでしょう

一時的なものかの判断は使い終わった後すぐに削除できるかどうか
削除できないのであれば、バージョン管理システムに保存し、ドキュメント等を書きましょう

ソフトウェア開発者の多くが行っているテストは品質管理であり、大きなストーリーの一部でしかなく、ソフトウェアエンジニアリングのライフサイクルは品質保証を伴う
品質保証は3つの部分からなる

データベース開発における品質保証

データベースの要件と実装はアプリケーションコードと同じように文書化すべき
以下のチェックリストを使って文書化しましょう

ER図
- テーブルとその関連を表す図
- 列・キー・インデックスなどを記すための表記法がある
- 図表作成用の製品のなかにはER図の表記法要素を含むものもある
テーブル・列・ビュー
- データベースを説明する文書も必要
- 説明する対象
  - 参照テーブル・交差テーブル・従属テーブル
  - 列の名前やデータ型
  - ビューの目的や想定されるテーブル間の関連
関連(リレーションシップ)
- スキーマ上の制約の根拠となるビジネスルール等の説明
トリガー
- トリガーに実装しているビジネスルール
ストアドプロシージャ
- どのような問題を解決するものか
- データに対する変更を行うか
- 入出力パラメータのデータ型と意味
SQLセキュリティ
- データベースユーザの定義
- 各ユーザのアクセス権
- システムレベルのセキュリティ対策　等
データベースインフラストラクチャ
- データベースの種類とバージョン
- データベースサーバーのホスト名等
オブジェクトリレーショナルマッピング
- アプリケーションコードに実装されるビジネスルール
- データの妥当性確認・データ変換

データベースサーバーが故障によって完全にダメになってしまった場合どうしますか？
変更を取りやめたい場合、どのように元に戻せばいいでしょう？

アプリケーションコードと同様にデータベースを扱うコードに対してもバージョン管理を用いましょう
バージョン管理下に入れておく、ファイル

品質保証の最終パートは、品質管理です
テスティングの重要な原則の1つは独立(isolation)です
テストごとにシステムの１部分のみを検証することで、欠陥が存在する場合に、可能な限り正確に、欠陥の箇所を絞り込める

アイソレーションテストはデータベースにも適用できます
データベースの妥当性を検証するテストのためのチェックリストを以下にしめす

アプリケーションの開発ではバージョン管理していると思いますが、データベースはバージョン管理の対象外です。
理想は、各ブランチ向けにそれぞれデータベースインスタンスを構築することです。
データベース接続パラメータが設定できるようにしましょう