0

データベースにバインドされている中規模のビジネス アプリケーションを考えてみましょう。このアプリケーションには、複数のテーブルに影響を与える多くのビジネス ルールがあります。たとえば、次の単純なものを見てください。

  • Personデータベースには、Customer、という名前のテーブルがありProspectiveCustomer、それぞれに「アクティブ」フラグが付いています
  • 個人は、顧客および/または見込み客になることができます
  • 同一人物である顧客と見込み顧客を同時にアクティブにすることはできません
  • 個人がアクティブでない場合、顧客または見込み客はアクティブにできません。
  • 請求書の発行とライフサイクルによって、誰がアクティブかどうかが決まります

このようなルールは複雑すぎて、データベース トリガーで強制することはできず、設計上の選択により、ダーティ ジョブを実行する集中化されたコードはありません。次に、テスト中に毎日気付くように、バグによってデータベースが一貫性のない状態に設定される可能性が常にあります。

これが本番環境で検出されないことを恐れているため、データベースの状態をチェックして不整合を報告するスクリプトを作成することをお勧めします。いくつかのアクティビティ ログに加えて、それは本番環境のバグに気づき、必要に応じてデータベースを修復するのに役立ちます。

この方法の唯一の欠点は、これらのセルフテスト スクリプトの開発時間が余分にかかることです (私の場合は無視できません)。基本的な何かが欠けていますか？

また、これらのセルフテストが記述されていれば、テスト活動にも非常に役立ち、開発の余分な作業負荷を最小限に抑えることができます。

4

2 に答える 2

2

これをデータベース レベルで行う場合は、チェック制約の使用を検討してください。

チェック制約でできることは、使用している RDBMS によって制限される場合があります。

このスレッドの SQL Server での複雑なチェック制約の例: http://social.msdn.microsoft.com/Forums/en/sqldocumentation/thread/1d4cf16b-9b37-4eb5-b66b-a428487f42c9

（編集：これをアプリケーションレベルで強制することが望ましい場合があります。これは、オプションである場合とそうでない場合があります）

于 2013-02-06T20:28:44.277 に答える
1

理想的には、データを操作するアプリケーションをテストして、ビジネスルールに準拠していることを確認します。一貫性のないレコードを見つけるよりも、誤って変更されたデータをトラップできる場合は、何が起こっているのかを理解する方がはるかに簡単です。テスト駆動開発は、この点で本当に役立ちます。

次に、理想的には、この種の不整合が発生しないようにデータベースをモデル化します。この例では、顧客や見込み客ではなく、「個人」レコードに「ステータス」フィールドを配置します。テーブル。

もちろん、理想的な世界というものはありません。

そのため、「ディフェンシブプログラミング」の概念が開発されました。多くの言語は、この種の一貫性のないデータからアプリを保護できるアサーションをサポートしています。私の考えでは、ビジネスルールと前提条件をコードに変換し、それらの前提条件の可能性に対処する必要があるため、これは大きな投資です。物事をさらに壊すことなく偽です。たとえば、このシステムの請求書発行アプリを作成している場合、「人」、「顧客」、「見込み客」のテーブルが同期していないと悪いです。通常、請求書の発行を許可するのははるかに悪いことです。コードにアサーションを入れると、これに対処するための構造化された方法が得られます。

私が取り組んできた多くのビジネスシステムには、データの有効性をチェックするための定期的な（夜間の）データベーススクリプトが含まれていました-多くの場合、検出したデータのバグは夜間のバッチで新しいチェックに変換されるというルールがありました。システムは時間とともに増加しました。

于 2013-02-06T20:51:21.023 に答える