0

私たちは企業情報システムを（再）設計しています。データベースの設計については、次のオプションを検討しています。

[オプション 1->] すべてを含む単一の CompanyBigDatabase、

[オプション 2->] 会社全体の複数のデータベース (HRD_DB、FinanceDB、MarketingDB など) をアプリケーションのレイヤーを介して同期します。EmployeeTable は HRD が所有しています。Finance が従業員を参照したい場合は、Web サービスを介して HRD_DB から EmployeeTable を照会します。

ベストプラクティスは何ですか? 長所と短所は何ですか？高可用性と適度な信頼性を実現したいと考えています。オプション 1 では、このためにクラスタリングとすべてが必要ですか? 大企業や大学 (Toyota、Samsung、Stanford Uni、MIT など) は常にオプション 1 を選択しますか?

多くの DB の教科書を調べましたが、このトピックに関する十分な説明が見つかりませんでした。

考え、ヒント、リンク、またはアドバイスは大歓迎です。ありがとう。

4

5 に答える 5

1

単一の答えはありません。それは、データベースの負荷、アプリケーション アーキテクチャ、スケーラビリティなど、他の多くの要因に依存します。私の提案は、可能な限り単純な方法 (単一データベース) から始めて、必要に応じて変更することです。

単一データベースには利点があります。結合が単純で、参照整合性があり、単一のバックアップです。正当な理由/必要性がある場合にのみ、データを分離してください。

于 2013-05-04T03:29:41.290 に答える
0

どちらでも機能し、他の決定は主に仕様に影響します。あなたの質問は、「ERP パスと SAAS パスのどちらに進むべきか」とある程度説明できますか? それは、現在、ほとんどのシステムが SAAS に向かっていることを示していると思います。

アプリケーションをどのように管理しますか? それらが異なる時間に更新される場合は、別々の DB の方が理にかなっています。(SAAS パス)。一方、接続先の DB、認証システム、詳細を検索する場所、バックアップする場所などを 1 つ持つことで、技術的なスペースの複雑さが軽減されるようです。ただし、ビジネスの一部に影響を与える決定を、ビジネスの他の部分とは別に検討することはできません。

ビジネスが関与すると、各部門がアップグレードに同意する時間を1回取得しようとすると、地獄になる可能性があります。スタックの一部を更新する前に 1 つの部門を調整するだけで済むように、ある程度の抽象化を行うことは、今後数年間で真の利点となります。また、Web サービスが堅牢で、リリースごとに変更されない場合、これははるかに簡単な方法です。

他の DB のデータを表示できることを忘れないでください。

そして、大企業はどのように機能するのかというあなたの質問については。一般に、大小のシステムが相互に通信する場合もあれば、通信しない場合もあり、データを繰り返す場合もあるシステムのミスマッシュによって発生します。データの繰り返しは本当の問題であると言いました。信頼できるソースとコピーを常に (または 1 つのコピーだけでもよい) 持ってください。私が多くの企業でうまく機能しているのを見た方法は、詳細を CRUD (作成、取得、更新、および削除) できる 1 つの場所と、それを読み取ることができる多数の場所を用意することです。

実際、この設計上の決定は、可用性と信頼性とはほとんど、またはまったく関係がありません。それは、優れた設計 (シンプルさ、どこに何があるかを知ることなど)、優れた実践 (優れたリリースの実践、管理の実践、バックアップ、インテリジェントな冗長性など) と支出から生じる傾向があります。1つまたは複数のシステムを持つことからではありません。

于 2013-05-04T04:29:30.910 に答える
0

私の意見では、データベースを正規化し、部門に基づいて会社全体に複数のデータベースを用意する方が適切です。これにより、情報の保存、取得、更新、および部門タイプまたはユーザー タイプに基づくユーザーへのアクセスの提供に関して、データをより効果的に管理できます。データベースのさまざまなビューを提供することもできます。データの管理がはるかに簡単になります。

于 2013-05-04T03:32:51.477 に答える