0

以前の回答に感謝しますが、彼らのフィードバックに基づいて、質問を修正しました。

質問に対する答えが「いいえ」の場合、他の手段によってデータの整合性を強制することができます。回避される可能性があるため、ストアドプロシージャの使用は十分ではないと思います。トリガーは必要ですか？

4

5 に答える 5

3

いいえ。一部のビジネス ロジックには計算が含まれます。もちろん、DBMS は計算を行うことができますが、それは参照整合性ではなく、「組み込み関数の使用による」ものです。

于 2011-11-22T13:09:43.410 に答える
2

伊達の最新の著書「Database Explorations」の脚注は、この質問に答えています。

「この事実は、考えられるすべてのデータベース制約が IND として表現できることを意味することに注意してください。」

IND は「包含依存関係」であり、基本的に SQL の外部キーと同じですが、SQL によって課される制限が除外されています。

編集

「トリガーが必要になるだろう」への回答: 「データベース プロフェッショナルのための応用数学」には、トリガーをプログラムして任意のビジネス ルールを適用する方法についての完全な専用の章があります。その章だけでも、この本を買う価値があります。

ところで、セキュリティシステムを使用してテーブルへのすべての「直接」アクセスをブロックする場合、sprocs は回避できません。もちろん、セキュリティルールが適切に定義および管理されていることに依存する必要があります...

于 2011-11-22T16:12:14.687 に答える
2

いいえ。CHECK 制約と FOREIGN KEY 制約だけでは表現できないビジネス ルールがたくさんあります。実際には、SQL での参照整合性制約のサポートでさえ、非常に制限されています。

たとえば、Employee と Department という 2 つのテーブルがある場合、すべての Employee を 1 つの Department に割り当てる必要があるというルールを簡単に適用できますが、すべての Department を少なくとも 1 人の Employee が参照する必要があるというルールを適用することはできません。技術的には、その効果に対する制約を作成できますが、SQL ではテーブルを更新できません!

ISO 標準 SQL には CREATE ASSERTION 機能があり、これは汎用の制約を強制するためのものですが、ほとんどの DBMS ではサポートされていません。たとえ利用可能であったとしても、CREATE ASSERTION 機能は、複数の代入に対する SQL の基本的なサポートが欠如しているため機能しません。一度に 1 つのテーブルしか更新できません。効果的なビジネス ルールの適用には、複数の割り当てを許可するデータベース モデルが必要です。

于 2011-11-23T06:41:50.457 に答える
1

SQL 用語では、参照整合性制約は通常、外部キーを意味します。

おそらく、データ整合性の制約を意味していましたか? もしそうなら、おそらくあなたの定義を拡張して と を含める必要がCREATE ASSERTIONありますCREATE DOMAIN。これにより、任意の複雑さの制約を適用できます。ただし、「任意のビジネス ロジック」は実際には不合理な要件であり、DBMS レベルですべてのビジネス ルールを適用することは望ましくない場合があります。

ご意見ありがとうございます。ただし、特に外部キーとチェック制約に関心がありました。

どういうことなんですか？一見、恣意的な分類のように見えます。

CHECK考慮している制約がサブクエリをサポートしているかどうかによって異なります。はいの場合、これは任意の複雑さの制約を許可しますが、更新されるテーブルでのみトリガーされます。つまり、CHECK制約定義に 2 つのテーブルが含まれる場合、2 番目のテーブルで補完的なCHECK制約が必要になる場合があります。

とはいえ、サブクエリをサポートする非常に強力な SQL 製品については知りません (Access データベース エンジンはサポートしていますが、非常に強力だとは思いません)。ただし、多くの SQL 製品は、サブクエリ (および手続き型コードなど) をサポートする回避策を提供しています。おそらく、あなたの定義ではティガーを許可する必要があります。

于 2011-11-22T14:45:13.103 に答える
1

データベース レベルですべてのロジックを使用することは可能ですが、単純なデータベース スキーマでは不可能です。ストアド プロシージャとトリガーを使用してデータベース レベルですべてのロジックを実装できますが、次のようにすることもできます。

  1. 実装が難しい
  2. メンテナンスが難しい
  3. すべての処理がサーバー上で実行され、クライアント マシンの能力を利用していないため遅くなります。

ストアド プロシージャを介してビジネス ロジックを実装する方がはるかに優れていると思いますが、サーバーに大きな負荷をかける可能性があります (クライアント数、トランザクション数などによって異なります)。

于 2011-11-22T13:09:00.383 に答える