メインコンテンツへスキップ
サインイン

MySQLの埋め込みSQLについて

dai
お世話になっております。 埋め込みSQLでメモリに読み込んだデータを、別のプログラムから参照することは可能でしょうか。 埋め込みSQLで集計を行う際、同様の処理を行うプログラムを複数本作成せずに済む方法を検討しております。もし効率的な方法や回避策についてご存じでしたら、ご教授いただけますと幸いです。 よろしくお願いいたします。

コメント

10件のコメント

日付 投票
  • Tanda

    daiさん、

    メモリテーブルとグローバル変数とトランザクション、この3つはコンテキスト毎に独立して管理されますので、そのままでは、そのコンテキスト以外のセッションからは参照ができないですよ。必要に応じて、普通のテーブルにコピーしてやる必要があると思います。

  • dai

    Tandaさん

    ご返信ありがとうございます。
    magicのリンク照会だと処理速度に問題があり埋め込みSQLを集計に使用し始めたところなのですが、埋め込みだとプログラム単位でSQL文が複製されるので保守メンテが大変だなと思い皆さんどうしようされているのかと思い質問させて頂きました。あまり多用されている方は少ないかと思いますが。

    これからさらに試行錯誤してみようかと思います。ありがとうございます。

  • nkmt

    埋め込みSQLとはSQLコマンドの事と思ってよろしいでしょうか？
    一切使わない人もいますがSQLコマンドを活用している人もいると思います。

    オンラインタスク単体でも集計結果を表示出来ますし便利だと思います。

    いろんな場面で同じ集計をする必要があるのなら、サブPGとして独立させて、結果はメモリテーブルや実テーブルに書き込んだ結果を使うようにしてもいいのかなと思います。

  • dai

    nkmtさん、こんばんわ

    いつもありがとうございます。
    本当にそうですね…どこで「埋め込みSQL」という言葉を拾ったのか、自分でも不思議です。。

    現在、社内には Magic を触れないものの他の言語は扱えるメンバーがいて、共同開発できないかと考え、まずはSQLコマンドに取り組み始めました。
    MagicのSQLコマンドからストアドプロシージャを CALL できることを確認できたため、請求書の計算処理などはストアド側に任せた方が処理速度的に有利ではないかと試行錯誤しているところです。

    特に正規化されたデータベースやリンク照会を多用すると処理が遅くなる傾向があるため、その解決策を探っています。

  • nkmt

    daiさん　おはようございます。
    こちらこそありがとうございます。
    私、ヘルプを確認不足でした。
    埋め込みSQLという説明がヘルプにもありますね。
    学び直ししたいと思います。
    埋め込みSQLとはDB SQL、SQLコマンド等を扱う事を指す総称なんだろうなと受け取りました。

    Magicの普通のプログラムの作りでも速度低下を招かぬよう売上伝票鑑部分だけに持てば良さそうな売上日や得意先コード、販売担当者コード等も売上明細データにも持たせる非正規化のテーブルを作りがちです。

    正規化されたデータベースで照会リンクを用いて範囲絞りを行うと、レコード件数が多いテーブル等では速度低下するのでしょうね。
    メインソースを１件読むごとに、照会リンクの本数分だけSELECT文が発行されているんだろうな、と思います。

    外部リンクや結合リンクを用いるとJOINされるみたいです。
    速度改善になるかもしれません。
    MySQLは私は未使用ですが、多分使えるのでしょうね。

    （自分は使いこなしておりませんが）オプション → 設定 → ロギング → DBMSを設定して、発行されているSQL文を比較するのもいいのかもしれません。

  • Sun nihara
    • 編集済み

    読みだすだけなら作り方で大分早さが変わってきますね
    ただ集計するときはSQLの方が早くって、月毎の集計テーブル作るときはプロシージャ
    ちょっとした集計が欲しい時は、保守性は最悪ですがSQL生成するサブプロを作って流してとるようなことをしていたり
    SQLコマンド

    SELECT :1
        FROM :2 
    :3 

    引数１　'MAX(' & VarDbname('A'var) & ')'
    引数２　DSOURCE('3'dsource)
    引数３　'WHERE '& VarDbname('A'var)  & ' > '& ' ''2025-09-03'' '

    Aが日付の項目、３dsource が集計したい売上のジャーナルみたいな感じで作ってます。

    仕様が固まってるならプロシージャとMAGICで分担できていいですね！
    うちはなんちゃってアジャイルなんで無理ですけど・・

    追記　
    正規化が進みすぎてるテーブル読むと照会リンクが増えて行単位で遅いのでビューを使うとよいかもしれませんね

  • KURITA

    流用できるような集計結果一覧ならプログラムを1本作成し(テーブルコントロールで結果表示)そのプログラムをサブフォームで表示する等も方法かと思います。

    抽出条件は異なるが結果項目が同じ一覧は上記のような形でサブフォームで表示したり、そのプログラム自信を子プログラムとして呼び出す等をしています。

    弊社ではOracleDatabaseでのSQLタスクは良く使っています。

    また、dai様の記載されていた抽出処理をストアドプロシェジャーで抽出しワークテーブルに結果を格納。Magicでワークを表示もよく行っています。

  • dai

    nkmtさん

    正規化やリンクの扱い方で速度に影響が出るのは知っていましたが、
    実際に開発していると「やむを得ず非正規化してしまう」場面が多いですよね。

    インデックスの重要性も改めて実感します。
    納品直後は問題なくても、データが増えてくると集計が徐々に遅くなる現象はよくあります。

    Magicにはまだまだ使ったことがない便利な機能や工夫の余地がありそうで、探ってみると新しい発見がありそうです。
    今回教えていただいたSQLログの確認やリンクの使い分けも、その一歩になりそうだと感じました。

  • dai

    Sun niharaさん

    ありがとうございます。
    なるほど、読み込みだけでも作り方で大きく速度が変わるんですね。
    集計のときはやはりSQLやプロシージャの方が早くなるのも納得です。

    例まで挙げて頂きありがとうございます。

    やはり仕様はなかなか固まらないことが多いので分担もちょうどいいバランスを見つけながらという感じです。
    magicはアジャイル的に開発を進められるのでいいですよね。
    うちもなんちゃってアジャイルです。

  • dai

    KURITAさん

    ありがとうございます。
    サブフォームや子プログラムで共通の一覧を流用する方法は、とても効率的で参考になります。
    抽出条件が異なっても結果項目が同じなら、この形でまとめられるのは便利ですね。

    Magicの良いところと苦手なところをいい感じで組み合わせでうまく使えるとさらに
    効率アップに繋がりそうですね。
    自分もこういったやり方を意識してみたいと思います。

サインインしてコメントを残してください。

お探しのものを見つけられませんでしたか？

新規投稿