問題タブ [dml]

私の他の質問「ログの DELETE を監査する最良の方法は何ですか?」に関連して。. に相当する PostgreSQL は何CONTEXT_INFOですか?

トリガーを使用して削除をログに記録したいのですが、データベース ユーザーをアプリの論理ユーザーとして使用していないためCURRENT_USER、レコードを削除したユーザーとしてトリガー コードからログを記録できません。しかし、INSERTとのようにレコードにユーザー フィールドを追加し、これらのフィールドを使用して監査テーブルにログをUPDATE記録できるため、トリガーからレコードの変更をログに記録することができます。inserted_bylast_updated_by

T-SQL と PL/SQL データ操作言語のコマンドを並べて比較した、優れたリファレンス カード/チート シートを探しています。

私は以前に SO を検索しましたが、この特定のテーマをカバーする古いスレッドはありません。そのため、両方のテクノロジーが混在する環境で作業する場合、そのような参照がほぼ必須であることを考えると、スレッドを開始することをお勧めします。共存します。

よろしくお願いします！

Oracleの組み込み認証メカニズムを使用してユーザーアカウントとパスワードを管理するアプリケーションに取り組んでいます。アプリケーションは行レベルのセキュリティも使用します。基本的に、アプリケーションを介して登録するすべてのユーザーは、「USERS」テーブルの通常のエントリではなく、Oracleのユーザー名とパスワードを取得します。ユーザーは、特定のテーブルのラベルも受け取ります。このタイプの機能では、多くの場合、DMLステートメントとDDLステートメントの実行を組み合わせる必要がありますが、DDLステートメントは暗黙的なコミットを実行するため、これは問題を引き起こします。DDLステートメントの実行後にエラーが発生した場合、トランザクション管理はすべてをロールバックしません。たとえば、新しいユーザーがシステムに登録すると、次のことが発生する可能性があります。

1. トランザクションを開始します
2. 人物の詳細をテーブルに挿入します。（つまり、名、姓など）-DML
3. Oracleアカウントを作成します（パスワードで識別されるユーザーtestuserを作成します;）-DDL暗黙的コミット。トランザクションは終了します。
4. 新しいトランザクションが開始されます。
5. より多くのDMLステートメント（挿入、更新など）を実行します。
6. エラーが発生し、トランザクションはステップ4にのみロールバックします。

上記のロジックが設計どおりに機能していることは理解していますが、このタイプの機能を単体テストしてデータアクセス層で管理するのは難しいと感じています。データベースがダウンしたか、単体テスト中にエラーが発生したため、ロールバックする必要のあるテストデータでテストスキーマが汚染されました。これが発生したときにテストスキーマをワイプするのは簡単ですが、実稼働環境でのデータベースの障害が心配です。これを管理するための戦略を探しています。

これはJava/Springアプリケーションです。Springはトランザクション管理を提供しています。

抽出して別のテーブルに配置したい列を持つテーブルがあります。

たとえば、Contactsという名前のテーブルがあるとします。連絡先には、文字列を格納するNameという名前の列があります。次に、Nameという名前の別のテーブルに名前を引き出し、Contact.Name列をNameテーブルのIDにリンクします。

これを行うにはSQLしか使用できません。これについて行くための最良の方法に関するアイデアはありますか？

何か明確にできるかどうか教えてください、ありがとう！

[編集]1つの問題は、異なる連絡先を同じ名前に関連付けることができることです。したがって、異なる連絡先が同じ名前を持ち、それがエクスポートされると、名前テーブルにはその名前の一意の行が1つだけあり、すべての連絡先がその行を指します。私が実際にコンタクトブックに取り組んでいる場合、これは意味をなさないと思いますが、私は自分の問題を説明するためにそれを使用しています。

DML は技術的には、クエリを実行するだけで永続データを変更しない SQL 動詞を含むことを理解しています。(たとえば、wikipediaまたはoracleまたはorafaqを参照)

ただし、「保存された/永続的なデータを変更するすべてのSQL動詞のみ」を参照したいことがよくあります-基本的INSERTにはUPDATE,DELETEですが、プレーンなSELECT. この DML のサブセットに対して、公式/標準化された用語、またはおそらく個別に、説得力のある優雅な用語はありますか?

パイプライン化された関数のドキュメントには、SQL ステートメント (通常は ) で使用される場合、DML は許可されないと記載されていますSELECT。ほとんどの例では、パイプライン化された関数はデータの生成または変換 (パラメーターとして顧客を受け入れる) に使用されますが、発行は行われません。 DML ステートメント。

現在、技術的には、Oracle からのエラーなしで SELECT を使用できます ( ORA 14551は発生しません)。ただし、選択の再現可能な奇妙な動作を経験しています。PRAGMA AUTONOMOUS_TRANSACTIONが使用されていなくても、によって取得された行は、常に現在のローカル トランザクションを考慮していないSELECTように見えます。これは、私にはバグのように感じます。さらに気がかりなことは、分散トランザクションを使用する場合 (たとえば、ローカル トランザクションではなく ORAMTS を介して)、トランザクションが使用されるという事実です。

編集: 結局のところ、奇妙な効果は、クエリ内のいくつかの WITH ステートメントに関連しているように見えますが、動作する場合と動作しない場合があります (少なくとも 10g では、Oracle オプティマイザーの現在の気分によって異なります)。場合によっては、ORA-32036 が表示されることがありますが、コードをまったく変更しないと発生しません。現在、ORA-32036 で失敗することがあるクエリは、正しいトランザクションの使用にも失敗しているクエリであり、パイプライン関数とは無関係である可能性があります。

したがって、私の具体的な質問は次のとおりです。

• SELECTパイプライン化されたテーブル関数の s が許可されているかどうか、およびそれらのトランザクションコンテキストは何か、できれば公式の声明はありますか?

• SQL ステートメントで使用できる一般的に使用されるクエリをモジュール化する別の方法はありますTABLE()か (テーブル関数で使用できるように)。

• 誰かがそのような行動を経験したことがあり、それについてもっと知っていますか? メタリンクを調べましたが、残念ながらこのトピックに関する特定の情報は見つかりませんでした。

こんにちは、トリガー本体でDMLコマンド/操作（挿入、削除、更新）を切り替えることができますか？私は理解を深めるためにいくつかのT-SQLをスニペットしようとしています：

ありがとう、

テーブルトリガー内で削除および挿入された論理テーブルに対してDDLステートメントを実行することの影響を見つけようとしています。私は持っている：

トリガーされると、エラーが発生することが予想されました。代わりに、create table ステートメントを完全に無視し、挿入された行を選択するようです。

この動作または説明を説明するドキュメントはありますか?

データベースのサブセットを分析するために、410 万件のレコードをオフライン システムにインポートしています。インポートを実行しているので、次を使用して進行状況を確認しようとしています。

奇妙なことに...さまざまな時期に、 の値が高くなったり低くなったりしていますRows。私はそれが上がることだけを期待します。出力のサンプルを次に示します。

この動作の説明はありますか? インポートの進行状況を確認するより良い方法はありますか?

次のバージョンを実行しています: サーバーのバージョン: 5.0.32-Debian_7etch11-log Debian etch ディストリビューション

編集：

これがDDLです。MyISAM テーブルです。

前もって感謝します、

-aj

mysqlのLAST_INSERT_ID（）関数は挿入の試行の間にリセットされないことを理解していますか（@@ Identityがsql-serverで行うように）...直前の挿入操作が失敗した場合、LAST_INSERT_ID（）は何でものpkを返します自動インクリメントの主キーを持つテーブルへのその接続の最後の挿入のpkはでした。そして、私がこれで正しければ、これは、この関数で思いつく可能性のある最も遅延した動作のように見えませんか？sql-serverの@@identityと同様に動作するmysql関数はありませんか？直前の挿入試行で新しいレコードが作成されない場合にNULLを返すものはありますか？あるいは、最新の挿入操作の主キーを確実に知るにはどうすればよいでしょうか。