1

私が住んでいる世界では、すべてのダーツを壁に投げつけ、一部が的を射ることを期待するソリューションを構築することは、かなり貧弱なソリューション方法論です。

それで、私の質問が生じINSERT IGNOREます.本番システムでの使用は、慣例によりいつ許容されますか?

TRIGGER既存のデータを検索する( #17353080を参照)を書きたい状況があります。見つからない場合はINSERTed. 提案は、ユニークなフィールドを使用INSERT IGNOREして依存することでした。primary keying

だから、私には苦境があります：

  1. 一意に保ちたいフィールドを使用INSERT IGNOREして依存し、繰り返される INSERT に失敗しますか?primary keying
  2. ターゲット テーブルに対して繰り返しクエリを実行して、一意に保ちたいフィールド値が存在するかどうかを確認し、存在しINSERTない場合は確認しますか?

これらの質問は、この特定の媒体で尋ねるには曖昧すぎるため、INSERT IGNORE を使用することが慣例によって許容される場合を理解したいと思います。また、特定のケースについては自分で判断できます。

ありがとう、

マット

メタ:

それ以来、次のようにconventions記述された既存のタグがあると思います。

ネーミング、スペーシング、コーディング、コメントなど、受け入れられている方法をカバーする一般的なタグ。

この種の質問は許容されます。

4

2 に答える 2

1

私にとって、これらの「機能」の警鐘は沈黙です。請求の世界では。あなたの理解に「ユニーク」な複数の記録を受け取ったとき。あなたはそれらについて知りたいです。スイッチが 30 ～ 100 列のレコードを認識するのは、電気通信の場合です。そのうちの 5 つはレコードを一意にします。ただし、キャリーは時々これを変更します。ここでの問題は、WAS の独自性がなくなったことであり、これについて知る必要があります。

もう 1 つの問題は次のとおりです。実稼働システムでは、重複を無視するだけで満足できるのはなぜですか? 少なくとも; 通常、データ ストリーム (着信) の上位に何らかのタイプの問題があることを示唆しているため、誰かが確認できるように重複レコードをログに記録する監査テーブルを作成します。

パフォーマンスに関しては...最新のハードウェアでは、これは本当に問題ですか? 大規模な更新を行うものは、クライアントとの対話性が高くない可能性があります (バックグラウンド プロセスである可能性が高い)。クライアントと対話型の場合は、テーブルのパーティション分割、優先順位など、状況を処理するためのデータベース サーバー設計のセットアップが必要です。

これに加えて; INSERT INGORED の警告により、これは恐ろしい機能になります。

  • NOT NULL 制約を持つ列に NULL を挿入する。
  • パーティション分割されたテーブルに行を挿入しますが、挿入した値はパーティションにマップされません。

データが想定されていない場所で NULL になったかどうかを知りたいと思います...

繰り返しますが、このコマンドは「その時点で何か良いこと」のように思えます。これは、私がミッキー マウス プログラミングと見なすものです。

于 2013-06-29T16:59:22.767 に答える
1

論理的には、失敗した場合に何をする必要があるかによって異なります。

バッチ挿入を実行しているだけで、値が既にテーブルにあるかどうかを気にしない場合 (値が一意である限り)INSERT IGNOREは賢明です。用語が示すように、挿入されていないものはすべて無視して問題ありません。

ユーザーにアドバイスするなど、失敗した挿入で何かをする必要がある場合は、別のチェックを実行する必要があります。

ただし、最も重要な質問は、「なぜ値が既にテーブルにあるのか?」ということです。

于 2013-06-29T16:40:44.063 に答える