UNIQUEは、あなたのフィールドをユニークにするインデックスです。しかし、新しいデータを挿入する前にすでにPHPで検証を行っている場合は、それを使用する価値がありますか？余分なINDEXは世界の終わりではありませんが、クエリの最適化を行っている場合は、UNIQUEが邪魔になりますよね？
5 に答える
12
あなたが優れたドライバーであり、総旅行時間を2秒節約できるのなら、なぜシートベルトを着用するのですか？
プログラマーが学ぶべき最も重要な教訓の1つは、彼は人間であり、間違いを犯すことです。 さらに悪いことに、このコードに取り組んでいる他のすべての人も人間です。
UNIQUE制約が存在するのはなぜですか？人間がミスを犯さないようにデータベースを保護するため。UNIQUE制約をオフにすると、「データベースさん、心配する必要はありません。私の意図に一致しないデータを提供することは決してありません」と表示されます。
一意性の検証が失敗するような何かがコードに発生した場合はどうなりますか？これで、コードは重複するレコードをデータベースにダンプします。ただし、その列にUNIQUE制約がある場合、フロントエンドコードが機能しなくなると、クエリが爆発します。
あなたは人間です。受け入れ。コンピュータにその仕事をさせて、あなたをあなた自身から保護するのを手伝ってください。
于 2013-01-20T08:30:44.167 に答える
4
UNIQUEは、データが有効であることを確認するためだけのものではありません。主な目的はクエリを最適化することです。データベースがフィールドが一意であることを認識している場合、最初のレコードが見つかるとすぐにヒットの検索を停止できます。巧妙に作成されたクエリだけでその情報をデータベースに渡すことはできません。
于 2013-01-20T08:26:14.277 に答える
4
それは興味深い質問です。
- コードをバイパスする方法がないことを確認しますか？
- PHPアプリケーション以外にデータにアクセスするものは他にありませんか？
- 複製が挿入された場合でも、アプリケーションの残りの部分が失敗しないことを確認しますか？
- 重複したエントリがあることの意味は何でしょうか、それは将来の参照または計算に問題を引き起こしますか？
これは、データベースレベルでの制約が解決に役立ついくつかの質問です。
最適化に関しては、制約によってデータの取得プロセスが著しく遅くなることはなく、実際には、インデックスに関連しているため、ある時点で実行プランで使用できます。
いいえ、最適化の邪魔にならず、データを不整合から保護します。
于 2013-01-20T08:30:12.883 に答える
3
pstが述べているように、開発のこの段階では、データベースまたは問題のアプリケーションの最適化を開始することはできません。
通常、システムに健全性チェックを追加することは悪いことではありません。はい、ほんの少しだけパフォーマンスを低下させていますが、CPUティックが1つか2つ余分にあることにユーザーが気付くことは決してありません。
これについて考えてみてください。今日はphpで検証を行いますが、データベースで一意性を主張しないでください。将来、あなた、同僚、またはあなたのプロジェクトをフォークした他の誰かが、元のphp検証を変更したり、それを台無しにしたり、完全に忘れたりします。この時点で、データベースに追加のチェックがあればいいのにと思うでしょう。
于 2013-01-20T08:29:04.290 に答える
0
tl：dr; （データベース内の）Transactional Integrityは、（アプリケーション内の）競合状態を処理します。
これらのRailsドキュメントの同時実行性と整合性のセクションでは、シナリオ例でこれが必要な理由を説明しています。
トランザクションの整合性を備えたデータベースは、分離によって一意性を保証しますが、アプリケーションは、トランザクションの分離の外で、特に大規模な競合状態に対して脆弱なままにする、実際にはいくつかの個別の手順（値を取得し、他の値があるかどうかを確認してから値を保存します）を実行します。
于 2013-01-22T18:07:37.643 に答える