データベースを使った自動テストについて
データベースを使った自動テストについて データベースを使った機能テストや単体テストについて要点をまとめておきます。 筆者の経験を強く反映していますので比較的定性的な内容となります事を予めご了承下さい。 テストデータを保守する テストの実行前に投入するテストデータは、凡そcsvファイルやxmlファイル、エクセルファイル等で管理する事になります。 仕様の変更に伴いテーブルの定義を変更する事で、それらのファイルの内容とデータベースの間に不整合が発生します。 テーブル定義の変更とテストデータの保守は常にまとめて作業するべきです。 これは同じ作業者がやるべきという事ではありませんが、ほぼ同時期に行われるべきです。 RDBを使っている場合、ExcelやAccessといったデータベースにODBC接続し易いツールを使うとデータを作り込み易いのですが、 テストデータを長期間に渡って保守する事を考えると、 テ
サロゲートキーと複合主キー | DBFlute
一方で、Webサービス系などで論理設計と物理設計をもう一緒くたにやっていくような場合は、 正規化の論理に目の前にあるサロゲートキーを含めないようにすることが大切で、モデリングはナチュラルキーを基軸に考えていくとよいでしょう。 サロゲートキー (代理キー) サロゲートキー + (複合)ユニーク制約 ナチュラルキーをPKにせず、例えば連番となるようなカラムを用意して、それをPKにします。 これがサロゲートキーと言われるものですが、ナチュラルキーには別途ユニーク制約を付与する というのを忘れてはいけません。 ここでは、ナチュラルキーにユニーク制約を付けずにサロゲートキーだけを導入する方式は、業務的・実装的に意味はないと考え、ここでは取り扱いません。 議論の対象にすらしません。ユニーク制約を付けることで業務的なユニーク性を保ちつつサロゲートキーの恩恵を得ることができ、同時にナチュラルキーを明示する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
削除フラグのはなし
