2

アプリケーションレベルで一意のキー制約があるテーブルでのデータ挿入/更新を処理する際のベストプラクティスは何ですか？これらは私が思いついたものです：

1.データを挿入する前にテーブルに対してクエリを実行して、データが制約に違反するかどうかを確認します。

長所

  • フルコントロールできるので、DBMS固有のエラーメッセージを処理する必要はありません。
  • データ整合性チェックの追加レイヤー

短所

  • ほとんどの場合、制約違反は発生しないため、パフォーマンスが低下する可能性があります。
  • 重複データのクエリを実行している間は、テーブルをロックする必要があります。

2.何もしません。テーブルを更新して、何がうまくいくかを確認します。

長所

  • 単純！
  • テーブルを更新するたびに追加のクエリを実行する必要がないため、全体的に高速になります。

短所

  • 検証ルーチンはデータベース層によって異なります。
  • データが固定されない場合は、スタックトレースを調べて、原因を特定する必要があります。

より広く受け入れられているソリューションはどれですか？これらに代わるものはありますか？

私はJava、JPA、Hibernate、SpringBTWを使用しています。フレームワーク固有の提案も歓迎します。

ありがとう！

4

4 に答える 4

3

あなたはすでにそれをかなり要約しています。パフォーマンスが懸念される場合は、2番目の方法を選択してください。誠実さが懸念される場合は、最初の方法を選択してください。

私は個人的にパフォーマンスよりも誠実さを好みます。ハードウェアはかなり安価ですが、完全性はありません。

関連する質問：

于 2010-12-20T19:44:12.230 に答える
2

3番目のオプションは、DBMSがMERGE操作（UPSERTと呼ばれることもあります）をサポートしている場合にそれを使用することです。通常、行が挿入されたかどうかをチェックするDBMS固有の方法があります。

トートロジーの「一意」キーは避けてください。キーはユニークなので、「キー」という言葉はあなたが何を意味するかを言うのに十分です。

于 2010-12-20T19:55:50.797 に答える
1

私は「楽観的な」アプローチ（「何もしない」）が好きです。あなたはすでにプロを列挙しました。この場合、検証をDBレイヤーに委任するのは正しいことです。ただし、JPAを使用している場合、DBレイヤーもJavaレイヤーによって生成されるため、実際の検証はJavaコードのアノテーションに依存します。したがって、それは大きな犯罪ではありません。

于 2010-12-20T19:45:54.147 に答える
1

通常、一意のキーはビジネス要件であるため、ビジネスレイヤーを使用して、使用するキーが使用可能かどうかを確認する必要があります。チェックをデータベースに委任することは最適化であり、必要な場合にのみ実行する必要があります。

于 2010-12-20T19:46:05.833 に答える