重複したユーザー名がデータベースに入力されるのを防ぎ、ユーザーに通知するために、挿入時に例外キャッチを使用するか、挿入する前にクエリを選択する方が標準的/推奨されますか?
例外キャッチ: ユーザー入力を挿入しようとしたときにユーザー名が既に存在する場合、SQL データベースは主キー制約違反の例外をスローします。それが起こったら私はそれを捕まえて何でもすることができます。
クエリの選択: ユーザー名に一致するタプルが返された場合は、挿入を気にしません。その後、エラーメッセージを表示できます。
ここで例外を使用する主な利点は、クエリと行が少ないことです (速度が向上しますか?)。ただし、重複はおそらくかなり頻繁に発生するため、これは例外的なケースではないと思います。
データベースはエントリの最後のポイントであるため、少なくともオプション 1 (主キー制約違反の処理) を使用する必要があります。最初の SELECT が返されてから INSERT ステートメントが返されるまでの間に遅延があり、別のユーザーがその時間枠内に同じ挿入を実行した可能性があるため、コード内の重複をチェックする場合 (可能性は非常に低いですが) 重複する可能性があります。
ただし、やみくもに挿入を毎回実行させるよりも、最初に選択を実行してレコードが存在するかどうかを確認する方が効率的です。
なので、両方をお勧めします。
このようにこれを行う「標準」は実際にはないと思います。クエリを実行してから挿入するか、INSERT /例外に進みます。
正しく適用すれば、どちらも正常に機能します。
私は通常、データベースにこのタスクを任せることを好みます。テーブルを変更して、一意にしたいフィールドが実際には一意のインデックスになるようにします。データを挿入しようとして、それが重複している場合は、次に何をすべきかを決定するために使用できるエラーが表示されます。またはON DUPLICATE KEY、必要に応じて代わりに別のテーブル操作を実行する場合は、(選択した RDBMS で使用可能な場合) を使用できます。
これにより、アプリケーションがそれらのテーブルに書き込むだけでなく、データベース側で問題が発生するのを回避できます。最初にクエリを実行する場合でも、しっかりとしたテーブルを作成するにはこれを行う必要があります。
データベースのクエリ レイヤーが複数の例外クラスを提供しない限り (リレーショナル データベースの場合は SQL 状態ごとに)、例外キャッチを使用しないでください。その場合、例外のメッセージに依存する必要があります。時間の経過とともに変化する可能性があります。