私は最近疑問に思っています。JSF + Spring + JPA / Hibernate(またはその他のテクノロジー)を使用してWebアプリを実行していて、「ユーザー」エンティティがあるとします。ユーザーに一意のログインを許可する必要があります。それを実行したい場合は、「ログイン」列に@UniqueConstraintを配置できますが、それでもアプリケーションは、ユーザー登録中に、ユーザー入力が有効(一意)であるかどうかをチェックする必要があります。これは、DB制約がある場合のみです。単にエラーが発生します。これは私に考えさせられました、DB制約は本当に必要/役に立ちますか?彼らが私たちに利益をもたらすと私が考えることができるのは、誰かが私たちをハッキングしようとしたとき(しかし、私たちのアプリはとにかくSQLインジェクションプルーフでなければならない)またはDBコンテンツを手動で変更しようとしたときだけです(これはすべきではありません)本当に起こります)。実は今考えてみると、DB制約は一般的に必要/グッドプラクティスですか?文字列の長さなどのように。
8 に答える
私にとっては、断固としてそうです。すべてのソフトウェアアーキテクトが知っておくべき97のThinksのDanChakによるデータベースをFotressとして参照してください。彼はそれが私よりずっと良いと言っています。
はい、そうです。これらは、最低レベルでデータの整合性を強化します。
DBコンテンツを手動で変更したい場合があります(つまり、新しいバージョンにアップグレードします)
コードの制約を確認するのを忘れる可能性があります。
これは、クライアント/サーバー検証のように見ることができます。プログラムはクライアント、dbはサーバーです。ほとんどの場合、クライアントの検証で十分ですが、問題が発生した場合に備えてサーバーの検証が必要です。
データ担当者は、両方が絶対に必要だと言うだろうと思います。あなたの質問は、中間層のアプリケーションコードがそのデータベースの前に今も永遠に存在することを前提としています。
真実は、中間層のアプリケーションが行き来するということですが、データは永遠に存続します。
スキーマ設計では、列の長さから逃れることはできません。中間層がそれらを強制するのは良い習慣であるかどうかをあなたは尋ねていると思います。そうではないかもしれませんが、それらはデータベースの鍵です。
多くの場合、列のセットを一意であると宣言するとき、それはクエリを実行する必要があるものです。したがって、とにかくインデックスを作成する必要があります。
はい、アプリケーションは適切なチェックを行う必要がありますが、間違いがすり抜けた場合はどうなりますか?データベースが何かが一意であることを意味していることを知っている場合、少なくとも、無効なデータ(または一意であることを意図したデータの複製などの「ひどく」無効なデータ)を保存しないことを知っています。とにかく、あなたは反対の質問をすることができます:それはあなたに何がかかりますか?
不良データが必要な場合は、データベース内の固有の制約を取り除きます。私は1970年代からデータベースに取り組み、何百ものデータベースに保存されているデータを照会またはインポートしてきました。アプリケーションレベルで制約が不適切に設定されているデータベースで、優れたデータを見たことがありません。アプリケーション以外の多くのものがデータベースにヒットします(他のシステムからのインポート、クエリウィンドウから実行されるデータの問題を修正するための製品データのクイックアップデート、他のアプリケーションなど)。多くの場合、アプリケーションが置き換えられ、制約が失われます。
しかし、それでも私たちのアプリケーションは、ユーザー登録中にユーザー入力が有効(一意)であるかどうかをチェックする必要があります。それがないと、DB制約がある場合にのみエラーが発生します。
それは私が今まで読んだ中で最も面白いものです。単にエラーが発生しますか?本当に必要なのはそれだけですか?エラートラップについて聞いたことがありますか?キャッチリングを試してみてください。
実際、アプリが「チェック」するのは非常に逆効果です。データベースはとにかく制約をチェックするので、なぜ2回チェックするのですか。アプリは、問題がないかのように行を挿入する必要があります。DBは一意性をチェックし、失敗するとエラーを発生させます...アプリはそのエラーをキャッチし、既存のチェックで行っていたことをすべて実行する必要があります。
一意の制約と外部の制約は、データの整合性を強制するだけでなく、パフォーマンスに影響を及ぼします。これらの「非公式」定数の知識がないと、データベースオプティマイザはステートメントの実行方法について予測できない決定を下します。
はい。キー違反エラーをキャッチするだけで、最初に追加のチェックの追加のオーバーヘッドを発生させることなく、キー制約が作業を実行します。