Q&A
質問者さんの中での用語の定義が不明です。
「サーバー」「アプリ」とは何を指していますか？
サーバー上で動くプログラミング言語はそのままアプリにもなるはずですし、
前提となる言語や環境があるのでしたらそちらを記載し（またタグに追加し）
より具体的なアドバイスを得られるように質問内容を再編してみてください
SQL を新規に学習しています。 ストアドプロシージャが、機能的および分業の面で便利な機能ということは理解できました。トランザクションやロックもストアドプロシージャで実施できるということですが、VB等アプリからもでき、
要するにどこまでをアプリに持たせ、どこまでをServerに持たせるのでしょうか。
Server, アプリの分担の塩梅もそうですが、SQL においても同様な悩みがあります。
たとえば View というのには種々のSQLが記述できますが「仮想テーブル」といわれるように、言葉がうまく説明できませんが、「所望のテーブル」を抜き出すに足るSQLを書くにとどめるべきなんでしょうか。
回答3件
0
ベストアンサー
要するにどこまでをアプリに持たせ、どこまでをServerに持たせるのでしょうか。
これといった正解があるわけではないので、なかなか難しいところです。
「どうやれば一番効率がいいのか」に尽きるのかな、と思います。
同じDBを多数のアプリが参照するような場合は、共通の参照方法をViewで、操作をストアドプロシージャ等で提供しているのは効率が良いかもしれません。
ただ、SQLには方言があるので、DBを乗り換える可能性があるようなシステムの場合、ストアドプロシージャ等がたくさんあると後で大変な事になります。
また、DBはスケールアウトが難しいので、ストアドプロシージャで重い処理を実装してしまうと、負荷が大きくなった時の対応が難しくなります。（アプリ側はアプリケーション・サーバーを増やすだけ（スケールアウト）で対応できるケースが多いので、DBよりは簡単）
あと、DBの方がテストが面倒だったり難しい傾向はあると思いますので、過剰に作り込むと大変だと思います。
なので、想定している使い方次第でバランスを考える必要はあります。
たとえば View というのには種々のSQLが記述できますが「仮想テーブル」といわれるように、言葉がうまく説明できませんが、「所望のテーブル」を抜き出すに足るSQLを書くにとどめるべきなんでしょうか。
使い方は自由ですが、Viewはクエリの繰り返しが多い場合のほか、特定のロールのユーザー以外には見せたくないようなデータを隠蔽するために使ったり、スキーマ変更に伴う互換性の維持に使ったりもします。
いずれにせよ、上記の通りDBの負荷は逃がしにくいので、極端に複雑な（負荷をかけるような）クエリを書くのはやめておいた方が良いです。
投稿2019/07/30 00:43
総合スコア8949
0
こんにちは。takasima20さんやgentaroさんの書かれた内容に便乗になってしまいますが、過去にSQL Serverでアプリケーション作成した経験があるので、少し書いてみますね。
（わたしの知識は５年前くらいで止まってしまっており、間違いも多いかもしれませんが）
保守性の面とか：
- 今後システムずっとWindows環境で構築するとか、SQL Server一本でやっていくということが前提なら良いかもしれません。
- ただし、ストアドプロシージャやストアド関数は、SQL以上に書き方がDBによって異なるので、そこは今後の保守性やリプレースの可能性を考えて作るほうが良いと思います。（そうすればよかった、という実体験からです）
移行はいつかやってくる：
- システムのリプレースだけでなく、データベースエンジンもしばらくするとサポート切れでバージョンアップを余儀なくされるので、どうしてもアプリケーション部分は変更なしでもデータベースを移行しなくてはいけないことが出てくるかと思います。
- 基本は下位のバージョンはサポートしますが、データファイルごと載せ替えでなく、少し不要なオブジェクトを整理して論理的に移行とかだと、スキーマなどなどでうまく参照できず動かなくなることもあるので、慎重さが必要かと思います。（やっぱり実体験から）
デバッグしにくい：
- これもはずかしい実体験からですが、調子に乗って業務ロジックを詰め込んだストアドプロシージャを作ったのですが、なかなかデバッグやテストしずらかった過去があります...
CRUD以外の処理でのリソースを消費する：
- いわゆるDBの責務である、SELECT/INSERT/UPDATE/DELETEといった基本以外に、ストアドプロシージャが動くことでリソースを消費することがあります
- アプリケーション側（外部のプログラム側）で実装できる処理なら、「いったんはSQLに慣れているからストアドで作ろう」という選択をしたとしても、処理が肥大化する前にアプリケーション側に切り出したほうが良いかと思います
このへんも、実行されるSQLでは負荷の高い処理を行なってないのに、なぜか反応がなくDBのリソースがかなり消費されてた、という苦い経験を踏まえてのことです...。
こんな感じです。
アプリケーション側はそのタイミングによっていろんな言語でリファクタされたり変わっていきますが、DBは思った以上に長生きします。
アプリケーション側だけでは担保できない、データ制約やインデックスといったものはきちんと設定しておくに越したことはないと感じてます。（バッチなど別経路で更新がかかる可能性があるので、不整合を発生させる可能性は防ぐほうが良い）
また、管理画面とか専用の操作で多数テーブル、スキーマをまたいでデータを見たいという場合はViewを用意するのは良いと思います。
ただし、フレームワークを利用したアプリケーションがViewに依存するのは、マイグレーションの時にちょっとピンとこなかったので、別管理、別スキーマをつかって定義というほうが良いのかなと個人的には思いました。
投稿2019/07/30 01:04
総合スコア1997
0
データベースの元々の発想ってのは、各アプリケーションが各々で
データアクセス部分を作りこんでるのって無駄じゃね?
という話もありまして、つまりは、共用できるものはひとつの
ところに作っておいて、それをみなで利用するのがいいよね。
って話かと。
翻って今回の場合は、特定のアプリしか使わないものはアプリで
共通に使えるものはデータベースで、って感じでよろしいかと。
あと、データベースサーバーは強いハード使ってるんで
お任せしたい部分がある、という経緯はあるかもしれません。
投稿2019/07/29 22:56
総合スコア7460
あなたの回答
tips
プレビュー
