Q&A
ご回答ありがとうございます。
BtoBのシステムで同時アクセス1000件程度に耐えうるのであれば問題ないと考えています。
大規模なシステムではありませんが、将来的にスケールしたときにネックにならないか心配しています。
確かに最初は利用者が少ないため、単一DBにまとめたほうが開発は楽になり、良さそうですね。
複数アプリケーションを単一データベースで運用するシステム構成の是非について
＜概要＞
業務効率化アプリケーションの開発を計画しており、システム構成を検討しています。
販売管理、購買管理、経費管理といった複数のアプリケーションが存在し、それぞれ単独で使用しつつ必要に応じてデータは連携したいと考えています。
認証基盤は一つだけ用意し、それぞれのアプリケーションにアクセス可否を登録したテーブルを設け、アクセス管理を行う予定です。
＜ご質問＞
ここですべてのアプリケーションのテーブルを一つのデータベース上に構築しようと考えていますが、通常想定される設計でしょうか。
単一データベースにした場合、以下の事項を懸念しています。
- 複数アプリケーションからのアクセスが集中するため、負荷がかかりやすい。
- テーブルが集約されていることでメンテナンスが難しい。
その他、アプリケーション毎にデータベースを分割し構築するということも考えられますがこのような設計はあり得ますでしょうか。
負荷分散にはなりそうですが、JOINが複雑になったり外部キー制約が使えないといったデメリットが考えられます。
システム構成を考えた経験が乏しく、アドバイスいただけると幸いです。
御礼
皆様回答ありがとうございます。
皆様の回答の方向性としては単一DBの設計を推奨されており、当初の予定通り単一DBに集約して開発したいと思います。
皆さんのご回答、非常に参考になりました。
ベストアンサーはスキーマの活用など、自分にはない視点でご回答くださった「Orlofsky」さんを選出させて頂きました。
回答3件
0
データの関連性が高い＝各システムの独立度が低いのであれば、１つでいいんじゃないでしょうか。
性能は何とでもなるというか、１つの箱であればDBを分けても負荷はあまり変わらないのでは？
あとは、運用面でしょうか。バックアップ要件がシステムごとに異なるとか、「ｘｘシステムのデータベースだけ止める」ということが無いかとか。
投稿2019/12/16 13:08
総合スコア84555
0
どの程度のアクセスを考えられておられるのでしょうか？
BtoCでかなりのユーザーが見込まれるような状況ででない限り、分散DBは考えない方がよろしいかと。
複数のアプリケーションが存在するなら、基盤や連携が重要です。
大規模になると基盤サーバやその他の業務サーバー構築して、連携のインターフェースを決めてなどとなってきますけど、
システム構成を考えた経験が乏しく
という方が設計されるなら、大規模という事はあり得ないと思いますので、コンパクトな設計にしておいて、習熟と規模の増大が共になる状態になった時にスケールアウトを考えるのが良いと思います。
利用者が少ないのに大規模なシステム構築をしてしまっては、コスパが悪すぎると思いますので。
投稿2019/12/16 12:21
編集2019/12/16 14:42
総合スコア25195
0
ベストアンサー
複数アプリケーションからのアクセスが集中するため、負荷がかかりやすい。
データベース・サーバーをそれなりの性能のハードウェアを用意します。
テーブルが集約されていることでメンテナンスが難しい。
基本的には、販売管理、購買管理、経費管理のシステム毎にデータベースのユーザー(スキーマとも)を分けて独立性を保てるように設計します。社員マスター、消費税率テーブルや顧客マスター、などのテーブルや共通関数(ストアド・プログラム)などをデータベース全体で共用する場合もあります。
必要な権限を与えて他システムと外部キーを設定することもできます。
別々のデータベース・サーバーを用意するとデータベース・リンクなどで他のシステムのテーブルを参照しなければならないので、データベース・リンクを多用するとパフォーマンスが落ちることもあるので、条件によってはMATERIALIZED VIEW を使ってパフォーマンスが落ちないようにする場合もあります。
投稿2019/12/16 11:42
総合スコア16415
ありがとうございます。なるほどですね。
各システムのDBアクセス用のユーザーをスキーマで区分することで独立テーブルや共通テーブルを管理するのですね。
サーバーの性能を上げてDB負荷を解消するのが通例なのですね。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/12/18 10:40