データベース制約をビジネスロジックにマップする必要があります

Question

データベースには、ユーザーのNAMEフィールドに固有の制約インデックスがあります。

service.GetUser(userName); 

経由

ビジネスサービスチェックは、ユーザー名が既に存在するかどうかを確認します。サービスのこの論理のために重複する名前を挿入することはできません。私はSqlExceptionの例外を一意制約違反のためのNumber = 2627でキャッチしません。

なぜNAMEフィールドに一意制約を設定するのですか？

Answer 1

サービス内のこのロジックのために重複する名前が挿入されることはありません。そのため、NAMEフィールドに固有の制約を設定する必要がありますか？

データベースの存続期間全体にわたって、アプリケーションがそのサービス以外のデータを追加しないことを保証する他の方法はないためです。

私がよく知っているdbmsには、コマンドラインインターフェイス、グラフィカルインターフェイス、およびバルクローダがあります。これにより、少なくともは、service.GetUser（）を経由せずにデータを変更するために使用できる3つのアプリケーションになります。

Answer 2

データベースレイヤーにUNIQUE制約を設定すると、挿入（または更新）のエントリポイントがどこに由来しても重複する名前は発生しません。たとえば、固有の名前を確保するためにアプリケーションレイヤーに置いておくと、誰かがコマンドラインから直接行を挿入したり、バッチスクリプトをアプリケーションのスコープ外に挿入するとどうなりますか？

IMOの場合、データベースレイヤーでこの一意的な制約の動作を維持する方がよいでしょう。

Answer 3

できるだけ多くのビジネスロジックをデータレイヤに配置する必要があります。リレーションシップ、一意性、長さ、最小長、値の制限、可能な限り。

アプリケーションが正しく配置されているとは信用しないでください。データのユーザーは、可能な限り破壊しようとします。私は個人的には、それを受け入れて後で修正するよりも、悪いデータを500回送る方が良いと思いますが、それは非常に争いのある問題ですので、

幸運。