sql - ビジネスルールにチェック制約を使用するのは良いことですか

Question

現在、ビジネス ルールの実装にチェック制約を使用していますが、ビジネス ルールを SQL で実装するか、ビジネス ロジック層 (C#) で実装するかを知りたいです。ネットで検索したところ、チェック制約が使いやすいことがわかりました。

詳しい情報を知っている人がいたら教えてください。もう 1 つは、モバイル アプリケーションと Web アプリケーションを使用して、データをデータベースに送り込むことができることです。

Answer 1

はい、それは良いです！

アプリ コード (ビジネス層) と、可能であればデータベースの両方でビジネス ルールを常にチェックする必要があります。

なんで？誰かがあなたのアプリを使わずにあなたのデータベースに何らかのデータを送信したと想像してみてください - もしあなたのチェックがアプリだけにあるなら、それらのチェックは適用されていません.

データベースにもチェックがある場合は、データベース内のデータが少なくとも SQL CHECK CONSTRAINTS で定式化できる単純なチェックに準拠していることを確認できます。

間違いなくそれらを使用してください！データ品質を可能な限り高く維持するように努める必要があります。データベースに参照整合性、チェック制約、一意制約などを追加すると、それが容易になります。

アプリだけに頼らないでください！

Answer 2

はい、チェック制約はビジネス ルールの有効なツールです。

しかし、チェック制約を使用する必要があるか、または外部キー関係を持つサポート テーブルを使用する必要がありますか? さまざまな場所で同様のチェック制約を定義していることに気付いた場合、答えは「はい」です。これは間違いなくサポート テーブルになるはずです。

データの整合性が重要です。アプリケーションが回避された場合、ビジネス ルールに違反するものを人が保存できるようにするシステムには、あまり価値がありません。また、元のアプリが C# であり、上層部が市場で Java/Ruby/Python などのバージョンが必要であると判断した場合に備えて、ロジックがデータベースにあると、作業がずっと楽になります。

Answer 3

可能な場合は必ず CHECK 制約を使用する必要がありますが、やり過ぎはしません。アプリケーションを使用せずにデータベースにデータを取得する可能性がない場合は、最小限の CHECK 制約と強力なビジネス検証で安全を確保できます。

SQL で厳密なビジネス ルールを定義するのはかなり難しい場合があります。データベースでのデータ検証と、アプリケーションでの実際のビジネス ルールに固執してください。

また、外部キーなどで不正なデータを入力しにくいようにスキーマを配置してください。

Answer 4

データベースがより「インテリジェント」であるほど、データベースに含まれるデータの整合性がより安全になります。ですから、はい、これは良いことであり、実装することが重要だと思います。

これには多くの利点があります。データを変更する複数のアプリケーション (例: C# アプリ + Web アプリ + モバイル アプリ ...) がある場合でも、データが安全であることを保証でき、作業を減らすことができます。それらの「二次」アプリケーション。データベースがすべての作業を行う場合、アプリはデータベースのフロントエンドにすぎません。

将来、アプリケーションの移行は容易になりますが、データベースの移行はより困難になります。これは重要な決定です。

Answer 5

制約による

1. それは制約に依存します
2. また、(可能であれば) 2 つの場所で同じ制約をチェックすることを避けるようにしてください。これは、システムに重複したコードがあり、不要な複雑さにつながることを意味します。

外部キー制約や一意性など、データベースに適用できる、または適用する必要がある制約がいくつかあります。データベースはこれらを迅速かつ効率的に適用できます。

他のより複雑な "ビジネス" 制約は、ビジネス ロジック レイヤーでより適切に適用されます。これらの例としては、「顧客は購入を許可する前に有効な電子メール アドレスを持っている必要がある」などがあります。これらは複雑で、データベースに適用するのは面倒です.SQLでシステムをコーディングするリスクがあり、これは悪い考えです.

Answer 6

C#. (私の経験では) SQL よりも C# でロジックを再利用し、一般的に維持する方がはるかに簡単です。