DB開発を行うときのベストプラクティス

DBの自動テストは遅く、管理が難しい
 
DBの変更は全て、人が読める形でバージョン管理システムで管理する。
 
DB定義の仕様書から、ワンクリックでDB定義のスクリプトが生成できること
    DB定義の仕様書は、Excelなどで作成することも多いが、この際、Excelのマクロでcreate table等の
    DBオブジェクト生成を行えるようにしておく。
    また、この際、直前の生成内容との差分を取れる仕組みを作っておくとChangeLogの自動生成も可能となる。
 
各開発者に個別のDB(スキーマ)を提供し、DBのセットアップを簡単に素早く行える環境を作ること
    複数人で開発を行っている場合、DBが1つしかないと
    また、この為に設定ファイルだけで、接続先DBを切り替えられるような構成をとる必要がある。
 
ワンクリックで、DBのエクスポート・インポートを可能にすること。
    エクスポートしたファイルは、タイムスタンプ付きのファイル名にし、複数世代管理可能とすること
 
UIの処理と、DB処理(トランザクション処理)を分離すること。
 
トランザクション処理は、統一されたインターフェースとなっていること。
    例えば、GUIアプリでボタンのクリックイベントハンドラ内に直接SQLを記述することも可能だが、
    この構成にしてしまうとDBのトランザクション処理をテストするだけのために画面操作が必要になる。
    また、UI処理とビジネスロジックを分離した方がプログラムの見通しも良くなる。
    引数、戻り値の数が可変個になる為、この点を考慮する必要がある。
    例えばC#のbackgroundWorkerクラスは、このあたりの処理をうまく行っている。
 
テスト用、デモ用、自動単体テスト用などのDBは、開発用のDBとは別に設けること
 
DB操作を受け持つためのデータアクセス層の用クラスを設けること。
    dbi,jdbc,ODBCやOADOなどのDBアクセスクラスをアプリケーションから直接コールすることは避ける。
 
DBの設定で、データをインメモリで管理できるようであればこの設定を使う。
それが無理なら、RAMディスクやSSDにDBを置けないか検討する
    開発・単体テスト時は、必ずしも大量データでテストを行う必要はない。
 
DBの整合性チェック用のスクリプトを作成し、各単体テスト後にスクリプトを実行して確認が行えるようにする。
 
自動で初期マスタデータ・テストデータをロードするスクリプトを設ける
 
テストデータを用意に生成できるための仕組みを設ける。
    エクセルのマクロでも良い。
 
単体テストを自動化する場合は、スキーマ定義の処理から再実行する。
    いわゆるcreate userやcreate tableを行う処理を最初に実行させる。
    この手段をとると、当然テストに時間が掛かるようになるが、インフラ部の変更に伴う不具合を
    早期に検出可能となり、メリットは大きい。
 
 
各テストを実行するたびに、ロールバックする。トランザクション内で勝手にコミットしていないかを確認する。
 
 
スキーマ定義のためのスクリプトを設け、バージョン管理に入れる
    テストを行うのが簡単になる
 
但し、大量データのテストや、マックス値のデータでテストすることも忘れてはいけない