DB(SQL Server)通信をDLLにしたいときストアドプロシージャは使わない？

Question

趣味でハードウェア（PLC)への通信ライブラリを作成しています。これはまあその界隈におけるユーザプログラマが最低限求めるであろう機能は実装したので、「MESシステム」を作るために便利なＤＬＬもあれば便利なのではないかなと思ってＳＱＬを勉強してゐます。

ＳＱＬを勉強してゐると、おそらく分業（アプリとＳＱＬの）のためだろうか、ストアドプロシージャというものがあります。これによればアプリ側でＳＱＬ文を書く必要はありません。

今回、私が作成したいＤＢ通信ＤＬＬは、ユーザ様にはユーザ様のＤＢのテーブルと対象カラムを指定していただいて、
ＤＢはそれをSQL文で並び替えたり抽出をし、アプリ側の一時的なテーブルに退避し、

つまり、
帳票から指定されたデータのDBへの登録（SQL実行）
↓
帳票から指定されたデータのPLCへの登録のためのデータ抽出（SQL実行）
↓
アプリ側でハードウェアとの通信処理に渡すためのデータ整理　（アプリ）
↓
ハードとの通信処理実行　（アプリ）

ということがしたいのですが、こういった「ライブラリ」を作成するとき、

SQLをストアドプロシージャに分担してしまいますと、そもそもユーザ様にその文だけの手数と技術的なことをかけさせてしまうので、ライブラリとしてのメリットが低減する気がするのですが、

やはりこういう場合は、必ずしもストアドプロシージャを使わずに、アプリ側でSQL(トランザクションや排他ロックも含めて）を持たせる（分担）させるわけなのでしょうか。

Answer 1

ストアドプロシージャというのは、ある程度の一連の SQL によるデータ操作の流れを、DB 側で定義してやることで、利用する側にその流れを意識させずに使わせる、ためのものです。
例えば DB に対してデータを登録する際に、制限をかけなくてはいけない（例えば試験の点数を登録するのだったら、マイナスの値は入ってはいけませんよね？）場合に、その制限を利用者側ではなく DB 側で保証してやることになります。

ストアドプロシージャは「データベース」に強く紐付くものなので、想定されているような状況では使うものではありません。

Comments

[yukijiro1990]

ご回答ありがとうざいました。

Answer 2

帳票云々はよくわかりませんが、PLCと連携するならリアルタイム性も必要になってくると予想します。
その場合、実行時間を安定させるためにストアドプロシージャを利用することも一手でしょう。
貴方が提供するシステムの一部としてDBMSを含めるなら、そこにストアドプロシージャがあっても
何の問題もありません。

Comments

[yukijiro1990]

>貴方が提供するシステムの一部としてDBMSを含めるなら、そこにストアドプロシージャがあっても

DBごとシステムとして提供する・・ということですね