ACIDから一貫性を落とすことができますか？
彼の著書「データベースシステムの概要」の中で、C.J。デイトは「ACIDの削除」と呼ばれるACIDの原則に関する章を書いています。この章では、彼は正しさ（一貫性）を「本質的に無意味」と呼び、他の原則はせいぜい「必要」と呼んでいます。
この本は2004年のものであり、インターネット上のどこに行っても、ACIDの原則をRDBMSアプリケーションプログラミングの指針と見なしています。それは、ACIDに対するDateのアイデアが受け入れられなかったことを意味しますか？または、理論的な観点からのACIDは、データベースプログラミングに関するインターネットドキュメントを読むときに見られるほど必須ではありませんか？
私の質問が意味をなし、正しいフォーラムにあることを願っています。
本の内容
著者は、非常に理論的な観点からACIDの概念を分析しています。
重要な部分は、章の最後の段落の最初の文かもしれません：
したがって、全体として、トランザクションの概念は、理論的なものよりも実用的な観点から重要であると結論付けます。
もう1つの重要な部分は、「複数代入」演算子（p。487）の導入です。これは、トランザクションをサポートすることによって実際のDBMSによって対処されるいくつかの問題の解決策として使用します。この操作は、 MySQL 、 Oracle または [〜＃〜] mssql [〜＃〜] では機能しないようです。 （1つのクエリで複数のテーブルを更新できるようにします。）
彼の声明は次のとおりです。この複数の代入演算子がある場合、制約の遅延チェックは不要であり、トランザクションの終了時ではなく、すぐに適用する必要があります。後者の場合、データベースは常に一貫しているため、ACIDの[〜＃〜] c [〜＃〜]は役に立たなくなります（ Cは一貫性を表します）またはその正しさは強制できません（Cが正しさを表す場合）。
[〜＃〜] i [〜＃〜]solationに関して、彼は、これはすべてのトランザクションが他のトランザクションが実行されている可能性があることをまったく知らないことを意味するはずだと主張します。これはおそらく実行不可能です。彼はさらに、ほとんどのDBMSが「分離レベル」設定を提供しているため、基本的にこの概念を損なうと述べています。
[〜＃〜] d [〜＃〜]彼が書いた耐久性は、ネストされたトランザクションがサポートされている場合、最も外側のトランザクションにのみ適用できます。
[〜＃〜] a [〜＃〜]彼によると、トミシティはトランザクションの必要性があるためにのみ必要です。複数代入演算子がアトミックとして使用できる場合、アトミックトランザクションは必要ありません。
何を奪うか
これは、ACIDの概念に関する非常に基本的な議論です。彼の批評家が正しいかどうかを判断することなく、トランザクションに基づくDBMSの生きた風景があります。
C.J.デイト自身は、「私たちは今、その研究の基礎となったいくつかの仮定をよりよく理解している」と書いています。これは、これが基本的な側面の1つであり、実際のDBMSでは簡単に変更できないことを意味します。トランザクションを削除し、アトミックな複数割り当て演算子をプッシュします。これは多くの変更であるため、企業はアーキテクチャを更新する必要がありません。
したがって、DBMSのプロパティを概念的に改善する方法、およびいくつかの問題を根本的に消去する方法を宣言する理論的な章を読みました。しかし、何かが優れているかもしれないという理由だけで、それはすぐに実際に使用されることはありません。
あなたは基本的に、単なる理論的な視点を持つ人と、理論以上のものが存在する実際の世界との境界に到達しましたが、既存の世界は包み込まれなければなりません。
ACID の整合性部分は、トランザクションの前、最中、後のデータの状態と関係があります。
参照整合性に関しては、外部キーを適切に接続し、キーを紛失しないようにする必要があります。つまり、カスケードルール、トリガー、および制約を取り巻くすべての操作は、オールオアナッシングである必要があります（最初から最後まで移動するか、情報が前後で同じに見えるように最後まで巻き戻します）。多くの場合、整合性はRDBMSの範囲を超えて、アプリケーションレベルで適用される可能性があります。どうして？
ビジネスロジックはますます複雑になり、RDBMSから一貫性を奪うアプリケーションコーディングが必要になる場合があります。特に、ストアドプロシージャが十分に強力でなく、クライアントがビジネスロジックを実行できる場合はそうです。
ACIDの一貫性は、RDBMS内のすべての処理（カスケードルール、トリガー、制約、DBMSに格納されているBI）に完全に適用されると言えます。これとは別に、BIを使用すると、ACIDの一貫性が無意味になります。結局のところ、データの整合性がアプリケーションレベルで処理されると、MySQLとSQLiteを使用する場合と同じように、OracleとSQLServerを使用してデータをマングルすることができます。
DB設計とアプリケーション設計には多くの予見が必要です。したがって、あなたはどちらかを言うことができます
- データは所有者の目にあります（DBMS）
- データはコーダーの目にあります（アプリケーション）
さらなる展望については、私の古い投稿を参照してください アプリケーションロジックをデータベースレイヤーに配置することに対する、またはそれに対する議論は何ですか？ （および提供される他の回答）DBAと開発者が一貫性を定義する絡み合いを確認するさて、私の他の古い投稿 アプリケーションコードを書く前にデータベースを設計する必要がありますか？ （および提供された他の回答）。
重要なのは、実際のSQLデータベースでは、エンジニアリング上の制約とアプリケーションの機能要件および非機能要件のために、理論的な範囲で原則を完全に実装できないということです。 「ダーティリード」、ネストされたトランザクション、遅延制約、プロセスとスレッドの同期の制限などを考えてください。