質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.04%

複数アプリケーションを単一データベースで運用するシステム構成の是非について

解決済

回答 3

投稿 編集

  • 評価
  • クリップ 0
  • VIEW 1,030

score 36

複数アプリケーションを単一データベースで運用するシステム構成の是非について

<概要>
業務効率化アプリケーションの開発を計画しており、システム構成を検討しています。
販売管理、購買管理、経費管理といった複数のアプリケーションが存在し、それぞれ単独で使用しつつ必要に応じてデータは連携したいと考えています。
認証基盤は一つだけ用意し、それぞれのアプリケーションにアクセス可否を登録したテーブルを設け、アクセス管理を行う予定です。

<ご質問>
ここですべてのアプリケーションのテーブルを一つのデータベース上に構築しようと考えていますが、通常想定される設計でしょうか。

単一データベースにした場合、以下の事項を懸念しています。

  • 複数アプリケーションからのアクセスが集中するため、負荷がかかりやすい。
  • テーブルが集約されていることでメンテナンスが難しい。

その他、アプリケーション毎にデータベースを分割し構築するということも考えられますがこのような設計はあり得ますでしょうか。
負荷分散にはなりそうですが、JOINが複雑になったり外部キー制約が使えないといったデメリットが考えられます。

システム構成を考えた経験が乏しく、アドバイスいただけると幸いです。

御礼

皆様回答ありがとうございます。
皆様の回答の方向性としては単一DBの設計を推奨されており、当初の予定通り単一DBに集約して開発したいと思います。
皆さんのご回答、非常に参考になりました。
ベストアンサーはスキーマの活用など、自分にはない視点でご回答くださった「Orlofsky」さんを選出させて頂きました。

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 3

checkベストアンサー

0

>複数アプリケーションからのアクセスが集中するため、負荷がかかりやすい。

データベース・サーバーをそれなりの性能のハードウェアを用意します。

>テーブルが集約されていることでメンテナンスが難しい。

基本的には、販売管理、購買管理、経費管理のシステム毎にデータベースのユーザー(スキーマとも)を分けて独立性を保てるように設計します。社員マスター、消費税率テーブルや顧客マスター、などのテーブルや共通関数(ストアド・プログラム)などをデータベース全体で共用する場合もあります。
必要な権限を与えて他システムと外部キーを設定することもできます。

別々のデータベース・サーバーを用意するとデータベース・リンクなどで他のシステムのテーブルを参照しなければならないので、データベース・リンクを多用するとパフォーマンスが落ちることもあるので、条件によってはMATERIALIZED VIEW を使ってパフォーマンスが落ちないようにする場合もあります。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2019/12/18 19:49

    ありがとうございます。なるほどですね。
    各システムのDBアクセス用のユーザーをスキーマで区分することで独立テーブルや共通テーブルを管理するのですね。
    サーバーの性能を上げてDB負荷を解消するのが通例なのですね。

    キャンセル

0

どの程度のアクセスを考えられておられるのでしょうか?
BtoCでかなりのユーザーが見込まれるような状況ででない限り、分散DBは考えない方がよろしいかと。

複数のアプリケーションが存在するなら、基盤や連携が重要です。
大規模になると基盤サーバやその他の業務サーバー構築して、連携のインターフェースを決めてなどとなってきますけど、

システム構成を考えた経験が乏しく

という方が設計されるなら、大規模という事はあり得ないと思いますので、コンパクトな設計にしておいて、習熟と規模の増大が共になる状態になった時にスケールアウトを考えるのが良いと思います。

利用者が少ないのに大規模なシステム構築をしてしまっては、コスパが悪すぎると思いますので。

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2019/12/18 19:45 編集

    ご回答ありがとうございます。
    BtoBのシステムで同時アクセス1000件程度に耐えうるのであれば問題ないと考えています。

    大規模なシステムではありませんが、将来的にスケールしたときにネックにならないか心配しています。
    確かに最初は利用者が少ないため、単一DBにまとめたほうが開発は楽になり、良さそうですね。

    キャンセル

  • 2019/12/18 20:00

    1000人の利用者がいるとして、同時アクセスの実効値はせいぜい2割の200人です。
    それでも分散させるというなら、ロードバランサーだとか高額な機器が必要になったりしますので、その辺も考慮に入れて検討された方が良いかと思います。

    キャンセル

  • 2019/12/18 20:39

    追加アドバイスありがとうございます。
    ロードバランサーですね。考慮に入れて検討したいと思います。

    キャンセル

0

データの関連性が高い=各システムの独立度が低いのであれば、1つでいいんじゃないでしょうか。
性能は何とでもなるというか、1つの箱であればDBを分けても負荷はあまり変わらないのでは?

あとは、運用面でしょうか。バックアップ要件がシステムごとに異なるとか、「xxシステムのデータベースだけ止める」ということが無いかとか。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2019/12/18 19:40

    ご回答ありがとうございます。
    DBを分けるという言葉にはDBサーバーを分けるという意味合いも含んでいます。
    運用面でシステム別に区分することで想定される点としてはカラムの追加やテーブルの増減といった点です。
    特定のシステムのDBだけ留めるといったことは想定していないです。

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.04%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る