問題タブ [prepared-statement]

列名とその列に挿入される値の連想配列とテーブル名 (単純な文字列) に基づいて、準備された INSERT ステートメントを生成する関数があります。

私の問題は、$this->conn->prepare (クラスの一部です。conn は新しい mysqli オブジェクトであり、問​​題なく動作します) は false を返しますが、その理由はわかりません!

以下は、prepare ステートメント用に作成される $sqlString のサンプルです。

このパラメータ化されたステートメントに問題がある人はいますか? prepare 関数が false を返す理由はありますか?

繰り返し SQL クエリを実行するためのベスト プラクティスと考えられるものは何ですか? 私の理解では、パラメーター化されたクエリを使用し、最初の実行時にそれを準備済みステートメントに変換します。このクエリを複数のスレッドで実行する必要がある場合はどうすればよいでしょうか? 各スレッドのクエリの種類ごとに準備済みステートメントを作成する必要がありますか? それとも、最近では SQL ステートメントの解析が非常に効率的になり、準備済みステートメントは不要になったのでしょうか?

時々、可変数のログ行をデータベースに挿入するデータベース ログ アペンダがあります。

SQL インジェクションを防ぐ方法で SQL ステートメントを作成したいのですが、サーバー側の準備済みステートメントを使用しないでください (選択ごとに可変数の行があるため、それらをキャッシュしても効果はありませんが、ここではパフォーマンスが低下する可能性があります)。 .

また、プリペアード ステートメントの便利さも気に入っており、文字列連結よりもプリペアード ステートメントの方が好きです。「クライアント側の準備済みステートメント」のようなものはありますか?

ejb3 でプリペアド ステートメントを使用して、Oracle にデータを挿入したいと考えています。使用可能ですか。

ネットで例を見つけようとしましたが、良い例が見つかりませんでした。

使い方を教えてください。または、ejb3 でパラメーター クエリを使用する他の方法はありますか (プリペアド ステートメントで ? を使用するため)。

感謝と敬意

問題

それで、私は Web ベースのアプリケーションを書いています。

私は現在、自分のクラスを書き直してい$dbますが、準備されたステートメントをどのように実装するべきかを理解するのにかなりの苦労をしています。

以前...

私はこのようなものを使用していました：

常に、select ステートメントを実行するときは、配列を取得して結果をループします。

という事は承知しています...

1. MySQL で準備されていないステートメントを使用することで、私は火傷を負わなければなりません。
2. 各変数がどのタイプのパラメーターであるかをmysqlに知らせる必要があります。（または私は）？

そうしたいです...

クエリと値を新しい関数 (例として select を使用します) に渡すことができます。これにより、(値の連想配列として) 操作する結果が返されます。

困っている...

すべての情報をまとめる方法を理解する。

1. 値の配列を提示し、それを準備済みのステートメントと一緒にまとめるにはどうすればよいですか?
2. 上記の mushed ステートメントを使用して、どのように実行し ( execute()?)、配列を返すようにしますか?

私の質問がやや回りくどい場合は申し訳ありませんが、理解しようとして困惑しています。さらに情報が必要な場合はお知らせください。追加します。

MySQLクエリブラウザはパラメータ化されたクエリのパラメータを設定できますか？もしそうなら、どのように？[パラメータブラウザ]タブにデータを入力しようとしましたが、クエリを実行したときに実際にパラメータが設定されていないようです。

私はグーグルでかなり長い間検索しましたが（例えば、mySQLクエリブラウザがパラメータ化されています）、答えを見つけることができませんでした。

私はmySQLフォーラムでこのスレッドを見つけました-ここで頭を悩ませているのは私だけではないようです。

重要な場合は、Windows Server 2008（クライアントとサーバー）でバージョン5.1を使用しています。

私は名前のリストを持っています。

と声明：

以下を行う方法：

回避策はありますか? このメソッドが欠落している理由を誰かが説明できますか?

使用: java、postgresql、jdbc3

コンソールからプリペアドステートメントを使用する方法を見たことはありません。APIからのプリペアドステートメントが必要なものを取得すると考えられるexplainクエリを実行するとはどういうわけか思いません。

これは私のこの古い質問に関連しています。

私は主にMySQLに興味がありますが、他のDBにも興味があります。

何百ものビジネス ユニットから毎晩レポートを受信するサーバーを開発しています。レポートは現在、暗号化された csv ファイルです。合計で、レポートは毎日 500,000 から 1,000,000 レコードに達し、後で使用するためにデータベースに保存されます。

送信ごとに一連の PreparedStatements を作成しました。これらのステートメントは、実行およびコミットする前に 50 レコードをバッチ処理するために使用されます。各レコードは、最大 20 のデータベース挿入を引き起こす可能性があります。送信がキューに入れられ、1 つずつ処理される場合は、すべて問題ありません。

これを同時に実行しようとしたときに、異なるスレッドが PreparedStatements のまったく同じインスタンスを取得していることに気付きました。これにより、次の問題が発生しました

1. 複数のスレッドが同じバッチにステートメントを追加しました
2. スレッドのいずれかがそうする時が来たと判断したときにバッチが実行されていました
3. 一部のスレッドが一部のステートメントを使用する時間がなかったため、データベースがその制約を満たしていないときにコミットが呼び出されました

問題は、ステートメント キャッシュから既存のステートメントを再利用する代わりに、準備済みステートメントを強制的に作成する方法があるかどうかです。

そうでない場合、状況を処理するためのより良い方法はありません

• ステートメント/接続プーリングを持たないバッチ用に別のデータ ソースを作成する
• データベースからの制約の削除。挿入順序はもはや問題ではありません
• 順次処理の強制

編集：問題を明確にする試み

スレッド T1 と T2 があるとします。準備されたステートメント S1 と S2 があるとします。バッチ B1 と B2 があるとします。

S1 が使用されるたびに、B1 に追加されます。S2 が使用されるたびに、B2 に追加されます。コミットするときは、外部キー制約ごとに S2 の前に S1 をコミットする必要があります。

問題が発生する場合

• T1は送信を喜んで処理します
• T2は送信を無邪気に処理します
• T1 はステートメント S1 を使用して、s1a を含むバッチ B1 に s1a を追加します。
• T1 はステートメント S2 を使用して、s2a を含むバッチ B2 に s2a を追加します。
• T1 は、コミットする時が来たと判断します
• T1 は、s1a を含むバッチ B1 をコミットします
• T2 は S1 を使用して、s1b を含むバッチ B1 に s1b を追加します。
• T2 は S2 を使用して、s2a、s2b を含むバッチ B2 に s2b を追加します。
• T1 は、s2a、s2b を含むバッチ B1 をコミットします
• 外部キーで禁止されている s1b の前に s2b がコミットされているため、データベースは「いいえ」と言います。

これは、手動の同期と回答で指摘することで回避できますが、各スレッドにローカルなロジックを適用するのではなく、各バッチのサイズを個別に追跡する必要があります。