design-patterns - データベース機能分解のパターン？

Question

次の問題があります。私たちのエンタープライズアプリケーションにはMySQLのデータベースがあり、その構造が複雑になりすぎているようです。100を超えるテーブルがあります（7年間開発されています）。

ただし、ほとんどのテーブルは他のテーブルとはまったく関係がありません。誰もが使用する一般的なテーブル（辞書）がいくつかありますが（そのようなテーブルは約20個）、それだけです。このデータベースをより高速で信頼性の高いものにする方法について疑問が生じました。

私はデータベースの分解についてたくさん読みました。つまり、さまざまなドメインに関連するテーブルをさまざまなデータベースに配置します。たとえば、運送状やその他の紙関連のものはすべてPapersというデータベースに配置され、顧客とその注文に関連するものはすべてClientsというデータベースに配置されます。

ここに2つの問題があります。

• ユーザーは、エンタープライズアプリケーションが単一のドメインで動作していることを確認する必要があります。開発者は、データベースを操作するコアをある方法で変更して、複数のデータベースに対応できるようにする必要があります。
• 共通のテーブルが問題を引き起こします。それらは単一のデータベースに保持する必要があり、分解後にすべてのデータベースに複製することはできません。したがって、クエリSELECT * FROM A JOIN Bを作成するにはどうすればよいですか？AとBは異なるデータベース（異なるサーバー上）にありますか？

どちらの質問も実際には同じ問題に対処しています。この問題を解決するための一般的なエンタープライズパターン（GoFなど）はありますか？特にJavaEEに適したパターンに興味があります。

Answer 1

テーブルのグループを独自のデータベースに移動することから始める必要はありません。これにより、システムがさらに複雑になり、複数のデータベースのバックアップの同期などの問題がさらに発生します。IMO 100 テーブルはまったく扱いにくいものではありません。

ただし、システム (およびデータベース) の機能を複数のシステムに分割する必要がある場合は、必ずそうしてください。明らかに、これにはシステムの大幅な変更や書き直しが同時に必要になります。

Re : 運送状、請求書など 残念ながら、MySQL はMS SQL Server のような他の RDMS のようにスキーマを実装していません。テーブル (PaperWaybill、PaperInvoice など) にプレフィックスを追加することで、スキーマ固有の名前空間をシミュレートできます。

ただし、システムが 7 年間運用されていることを考えると、現在テーブル名を変更することはおそらく賢明ではありません。また、すべての依存関係を特定するのは難しい場合があります。たとえば、いくつかのアプリケーション、レポート、ジョブなどがすべてこれらのテーブルにアクセスしている可能性があります。

IMO関係が非常に少ない理由の核心に迫る必要があります。関係は存在する可能性がありますが、パフォーマンス上の理由FOREIGN KEYSなどで削除された可能性があります。これがシステムの図を作成する能力を妨げている場合、または ORM コード ジェネレーターなどのツールが関係を作成するのを妨げている場合は、PROD データベースを DEV 環境に復元し、外部キーを DEV に戻すことができます。同時に、FK 制約など、データの品質についてのアイデアを得ることができます。