PEP 249 -- Python データベース API 仕様 v2.0の説明の.commit()には次のように記載されています。
データベースが自動コミット機能をサポートしている場合、これは最初はオフにする必要があることに注意してください。再びオンにするためのインターフェースメソッドが提供される場合があります。
ほとんどのデータベースがデフォルトで自動コミットすることを考えると、その背後にある理論的根拠は何ですか?
1 に答える
5
Discovering SQLによると:
トランザクション モデルは、ANSI/ISO SQL 標準で定義されているように、トランザクションのすべての論理ユニットの実行が成功した場合、または明示的な ROLLBACK の場合に明示的な COMMIT を使用して、トランザクションの暗黙的な開始を利用します。コミットされていない変更をロールバックする必要がある場合 (たとえば、プログラムが異常終了した場合)。ほとんどの RDBMS はこのモデルに従います。
つまり、SQL 標準では、トランザクションは明示的にコミットまたはロールバックする必要があると規定されています。
明示的なコミットを行うケースは、SQL-Transactionsで最もよく説明されています。
SQL Server、MySQL/InnoDB、PostgreSQL、Pyrrho などの一部の DBMS 製品は、デフォルトで AUTOCOMMIT モードで動作します。これは、すべての単一の SQL コマンドの結果
が自動的にデータベースにコミットされることを意味します。したがって、問題のステートメントによってデータベースに加えられた影響/変更はロールバックできません。そのため、エラーが発生した場合、アプリケーションは作業の論理単位に対して逆の操作を行う必要がありますが、これは並行 SQL クライアントの操作の後では不可能な場合があります。また、接続が切断された場合、データベースは一貫性のない状態のままになる可能性があります。
つまり、自動コミットの代わりに明示的なコミットを使用すると、エラー処理と操作の取り消しが非常に簡単になります。
また、Pythonメーリングリストのユーザーを観察したところ、自動コミットがデフォルトでオンになっているのは良くないというのがコンセンサスでした。
ある投稿は次のように述べています。
自動コミットは悪いことであり、ODBC の非常に邪悪な発明です。ODBC ドライバー (トランザクションをサポートしていないドライバー) の作成は簡単になりますが、場合によっては潜在的に危険です。たとえば、プログラムがクラッシュする場合があります。データが有効で、どれがそうでないか。「ミッション クリティカル」(私はその用語が好きです ;-) データを処理する商用アプリケーションは、自動コミット モードで実行する必要はありません。
別の投稿は次のように述べています。
重大なアプリケーションは、独自のトランザクションを管理する必要があります。そうしないと、障害モードを制御することは期待できません。
私の印象では、Python 開発者はこの種の情報を考慮に入れ、デフォルトで自動コミットをオフにすることの利点 (エラー処理とリバースが容易になる) が、自動コミットをオンにすること (同時実行性の向上) の利点よりも重要であると判断しました。
于 2014-03-04T04:40:15.907 に答える