0

ROLLBACKデータのインポート、データの検証、および実行にoracleコマンドを使用することは適切ROLLBACKですか?

ERP 用に構築されたデータ インポート プログラムがあり、コードを見て、データを実際のテーブルに挿入し、検証し、検証に失敗した場合は ROLLBACK を実行します。挿入する前に常にデータを検証してきましたが、これが信頼できる受け入れられた方法であるかどうか知りたいですか?

4

1 に答える 1

0

ここで覚えておくべきことがいくつかあります-

  • 制約により、データの整合性を維持できます。これは、制約により、データベース レベル自体でビジネス ルール (または少なくとも最も基本的なルール) を適用できることを意味します。

  • acommitまたは arollbackは、トランザクションで行われた変更を保存または元に戻す方法です。commit一連の DML ステートメントが正常に実行された後に を発行すると、変更が保持されます。このrollbackステートメントは、変更を元に戻します。

  • 一連の DML ステートメントで、そのうちの 1 つが失敗すると、その特定のステートメントの効果がロールバックされます。たとえば、UPDATEステートメントが 10 行を更新し、そのうちの 1 つが重要な制約に違反している場合、10 行のいずれも更新されません。ただし、前のステートメントの影響は暗黙的にロールバックされません。

  • データの整合性を維持し、ビジネス要件に従ってデータを保持するためにROLLBACK、DML のいずれかが失敗した場合は手動ステートメントを発行する必要があります。

  • プログラムで見ているのは同じプラクティスです。ROLLBACKコードをよく見ると、トランザクションが成功した後には発行されませんが、DML が失敗した後にのみ発行されます。これは、失敗時にロールバックし、すべてがうまくいった場合にのみコミットすることをお勧めします。

  • データのフロント エンド チェックは、実際、あらゆるアプリケーションの重要な部分です。これにより、入力されるデータがビジネス ロールに準拠することが保証されます。この場合でも、データベース レベルでチェックを実行するには、制約を適用する必要があります。これは、新人がフロント エンドに変更を加え、無効な​​データを入力しようとする場合に特に役立ちます。これは、誰かがアプリケーションをバイパスして手動でデータを入力している場合にも役立ちます。したがって、データベース レベルに制約を設定することは常に必要です。

于 2013-10-18T03:53:21.827 に答える