これはMySQLストアドプロシージャを論理的に使用していますか？

Question

私は本当に単純なストアドプロシージャを追加するように開発者が依頼し続けているホストされたMySQLデータベースを持つクライアントを持っています。このようなストアドプロシージャを見ると、ストアドプロシージャとして実装され、アプリケーションコード内に実装されない理由は何もありません。これはストアドプロシージャの使用が本当に奇妙なものであることを訂正していますか？

CREATE DEFINER = 'username'@'%' PROCEDURE `sp_get_payrollgl`(IN pi_glcode TEXT) 
    DETERMINISTIC 
    CONTAINS SQL 
    SQL SECURITY INVOKER 
    COMMENT '' 
BEGIN 

    if (pi_glcode is null || pi_glcode = '') then 
    select glcode,descr, 
     case when crdb = 1 then 'CR' else 'DB' end as 'crdb', 
     case when taxable = 1 then 'Yes' else 'No' end as 'taxable', 
     case when billable = 1 then 'Yes' else 'No' end as 'billable', 
     case when active = 1 then 'Yes' else 'No' end as 'active' 
    from payrollgl; 
    else 
    select glcode,descr, 
     case when crdb = 1 then 'CR' else 'DB' end as 'crdb', 
     case when taxable = 1 then 'Yes' else 'No' end as 'taxable', 
     case when billable = 1 then 'Yes' else 'No' end as 'billable', 
     case when active = 1 then 'Yes' else 'No' end as 'active' 
    from payrollgl where glcode = pi_glcode; 
    end if; 
END; 

Answer 1

このような単純なルーチンでは、この特定のストアプロシージャの目的を達成するためのより良い方法があります。たとえば、設定ファイルにあらかじめ定義したり、定義済みの配列オブジェクトとして格納したりするなどです。

個人的には、バックエンドで実行する必要のある複雑な一連の命令、特に異なるテーブル間で大量のデータを操作する必要がある場合は、ストアドプロシージャを実装します。メリットは明らかに、あまりに多くのラウンドトリップやデータベースへの接続がないため、経験するオーバーヘッドを最小限に抑えることができます。

私は、ストアドプロシージャを使用して、フロントエンドの開発者からの複雑な詳細や内部の動作をカプセル化するビジネスロジックを定義することがあることがあります。もう1つの利点は、システムを正しく設計すると、ストアドプロシージャを使用することで、可能な限り多くのスケーラビリティが実現できることです。

これは、QAからUATへの開発のような異なる環境で開発を行う場合に特に役立ちます。どこかでサービス内のコード行を変更する必要がある場合は、そのサービスを削除して再配置して変更を反映させてください。もちろん、多くの混乱を招く可能性があります。ストアプロシージャを使用すると、単純に変更することができます。がんばろう！