回答受付終了まであと5日

kit********

2020/9/27 11:38

33回答

2「処理はアプリ側でもたせるべきか、RDBMS側にもたせるべきか?」 ちょっとおもしろい記事をみかけました。

2「処理はアプリ側でもたせるべきか、RDBMS側にもたせるべきか?」 ちょっとおもしろい記事をみかけました。 https://sikushima.hatenablog.com/entry/20100607/1275889891 筆者の方は、処理をDB側でもたせることにより、生産性が劇的に上がるとおっしゃっています。 しかし、半径５m以内では、仕様変更があった場合、アプリ側のソースコードを変えたくないばっかりに、新規ストアドプロシージャに作り、それが繰り返された結果、似たようなストアドが乱立する状態になりました。さすがに使用してないと完璧に分かっているストアドはエイヤッと削除しますが、SQLは書き方に自由度が高く、ましてやストアドに関してはDB間の互換性が低いです。どうしてもDBサーバ側で処理をしたい、や、一時的になつじつま合わせぐらいならともかく、 長期間にわたりメンテナンスする場合や、DBが変更される可能性がある場合は、込み入った判断分岐はストアド側ではなく、アプリ側で処理したほうがいいんじゃないか？とおもうのですが。（いまではアプリ側にもLINQがあり、ある程度互換性あります） そもそも、仕様変更があった場合は、どうなさっているのでしょう？まさか、古いストアドはそのまま置いといて、新しい条件に基づくストアドを立ち上げなさっているわけじゃないですよね。それは時代の流れに逆行です。アプリ側ならオーバーライド,オーバーライトいろいろ手ありますが。。。 みなさまは、ストアドプロシージャのデバックはどうなさっているのでしょうか？？

補足

ありがとうございます 質問したいことは「アプリ側の言語が一択決め打ちで、DBの選択が変わる可能性があるのになぜわざわざRDBMS側に処理を持たせようとしようとするのか？」です 問題の一つにDB（特にオラクル）の値段が高いからです。これから先の将来、より安く(つまりタダ)、高性能なRDBMSが出てくれば、営業側からのコスト圧で乗換える可能性が出てくるでしょう。その時、せっせと蓄えたストアドプロシージャの遺産はパァーです 一方、アプリ側のアプリはプログラマ自身の乗換えのコストが高いので、アプリ側の言語が煩雑に変わることはありません 特に質問の意図は 「ストアドプロシージャのデバックをどうするか？」です SQL自体は百歩譲って互換性がある（？）としても、この筆者の主張は「ストアドプロシージャに依存せよ」です。そりゃJOINバラして、いっこいっこ追っていけば、バグ発見できますよ。でもそんなのシェルスクリプトレベルのデバックですよね IDE側が進み、単体テストでさえ簡単に切出せるようになっているのに、なぜ貧弱なデバック環境で、しかも他DBと互換性のないストアドプロシージャ押しなのか、解せません

データベース | プログラミング・31閲覧

ログインして回答

回答（3件）

1

jhotqy

2020/9/28 14:30

リンク先の記事は、2010年のものなので、今はまた違う様になって来ていると感じますが、私の個人的な意見です。 「処理はアプリ側で持たせるか、RDBMS側で持たせるか？」ということですが、処理速度を上げるのに有利なのは、RDBMS側に持たせることだと思います。ただ、RDBMSには不足するライブラリがあると思います。その様なルーチンはアプリケーション側で処理したほうが速度が出るでしょう。その場合もDBサーバでアプリケーション処理をした方が良いでしょう。 もう片方の視点として、メンテナンス性やアプリケーションの拡張性に目を向けると、これは間違いなくアプリケーション側で処理を書く方が圧倒的に良いでしょう。ただし、この視点の場合は、処理の責務分けをしっかりすることが大切な様に思います。あくまでデータの保存や単純なデータ整合性を担保するための処理は、DBMS側の責務としてDBMSに処理を実装した方がメンテナンス性は上がるのではないでしょうか？そのレベルであれば、DBMSの変更に対しても大きな負荷にはならないのではないでしょうか？ アプリケーション処理に関しても、今の時代は、クライアント端末で行うのではなく、サーバ側でRPC（例えばWebAPIなどをコールする）の仕組みを作り、クライアント側のアプリではアプリケーション固有処理はあまりせず、サーバ側でアプリケーション処理をする様になって来ている様に思います。 ですので、私はデータ保持・保存に関わる処理は、RDBMSで持たせ、アプリケーションの主たる処理はアプリケーションサーバでアプリケーション側に持たせ、ユーザーとやり取り処理はクライアント端末に実装するプログラムに処理させる（いわゆる3層構造）が良いのでは？と思います。

1人がナイス！しています

kit********

質問者

2020/9/28 22:09

ありがとうございます。まさしく納得する御回答でございます。 あまりに「ストアドプロシージャ押し」の人がいらっしゃるので質問してみました。 （また、「ストアドプロシージャのデバックをどうするのか？」という疑問にも御見識をいただけると幸いです）

1

ikt********

2020/9/27 17:59

>筆者の方は、処理をDB側でもたせることにより、生産性が劇的に上がると >おっしゃっています。 ご紹介リンク先拝見しました。 けど、それが成り立つ前提も、書いておられるように私には読めました。 ---- SQLもオブジェクト指向言語も両方とも十分に熟達している技術者が行えば、... --- というあたり。 そういうエンジニアの存在が前提だってことです。 結局 ・人依存 ・TPOによる んじゃないでしょうか。 SQLに熟達している技術者 は、実はそんなに多くないんじゃないか？ と個人的には、思っています(根拠はないです、なんとなく経験から)。 リレーショナルモデルやクエリ言語SQLはかなり偉大な発明(?)だと は思ってますけど、熟達してる人は意外と少ないじゃないかと。 ・非手続き だからです。 大多数のプログラマは、 ・変数の変化 という副作用を残しつつの ・順次手続き のパラダイムに、良くも悪くも慣れています。 SQLはそうではなく、異質なものです。 手続き状態変化パラダイムになれたプログラマから見れば、 複雑な select や、join 等は、逆にインピーダンスミスマッチで 難しいのじゃないかと。 そういうエンジニア多数なチームなら、自然と見知った アプリケーションコード側で手続き的に解決しようとなるのは ある意味自然なことです。 私は、SQLのすばらしさは否定しないけれども、 一部の礼賛者(?)な型が持ち上げるほどに万能なものとは、 正直思っていません。 使いこなせる人は限られます。 適性もある気がします。

1人がナイス！しています

0

nan********

カテゴリマスター

2020/9/27 15:43

> DBが変更される可能性がある場合は、込み入った判断分岐はストアド側ではなく、アプリ側で処理したほうがいいんじゃないか？ まさしくこのような場合にDB側に処理を持たせた方が有利ですね。 アプリ(というかアプリサーバー)側でやるとしたらおそらくなら一つの変更が複数の処理に関わる可能性が高いですが、DB側なら局所的ですみます。 ちなみに、アプリ(つまりクライアント側)ではあくまでもUIに関わる処理だけにする方が良いです。DBに関係した部分はアプリサーバーに持たせます。 似たような処理が乱立する、ということならアプリサーバー側でやる方がよほど乱立する可能性は高いです。 DBが切り替わることのストアドの互換性についても、じゃぁアプリサーバー側でやれば言語変更などによる互換性の問題が出てきますから、基本的にリスクは変わらないどころか、DB側に集中している方が処理数は少なくて済むでしょう。 DB側に処理を持たせることの問題とはそのようなものではなく、基本的にはDB(特にRDBで更新側)は分散することが難しくクライアント増に対応するのが難しい点です。 アプリサーバー側に処理を持たせれば分散するのは簡単です。