데이터베이스 기능 분해 패턴?

Question

우리는 다음과 같은 문제가 있습니다. 우리의 엔터프라이즈 애플리케이션은 MySQL에 데이터베이스를 가지고 있으며, 구조가 너무 복잡 해져서 100 개가 넘는 테이블 (현재 7 년 동안 개발 중)이 어디에있는 것처럼 보입니다.

그러나 대부분의 테이블은 다른 테이블과 전혀 관계가 없습니다. 모든 사람 (약 20 개의 테이블)이 사용하는 공통 테이블 (사전)이 있지만 그게 전부입니다. 이 데이터베이스를보다 빠르고 안정적으로 만드는 방법에 대한 의문이 제기되었습니다.

데이터베이스 분해에 대해 많이 읽었습니다. 즉, 다른 도메인에 관련된 테이블을 다른 데이터베이스에 배치합니다. 예를 들어, 운송장 및 기타 종이와 관련된 것은 종이라고 불리는 데이터베이스에 저장되고 고객 및 주문과 관련된 모든 것은 클라이언트라고하는 데이터베이스에 저장됩니다.

• 사용자는 단일 도메인에 작용하는 등의 엔터프라이즈 응용 프로그램을 볼 수 :

  여기서 우리는 두 가지 문제가있다. 개발자는 여러 가지 데이터베이스를 처리 할 수 ​​있도록 데이터베이스와 관련된 핵심 작업을 변경해야합니다.

• 공통 테이블에 문제가 발생합니다. 단일 데이터베이스에 보관해야하며 분해 후 모든 데이터베이스에서 복제 할 수 없습니다. 따라서, 우리는 어떻게 질의를 만들 수 있습니까? SELECT * FROM A JOIN B, 거기 A와 B는 서로 다른 데이터베이스 (다른 서버)에 있습니까?

이 두 가지 질문은 실제로 동일한 문제를 해결합니다.이 문제를 해결하기위한 일반적인 엔터프라이즈 패턴 (예 : GoF)이 있습니까? 특히 Java EE에 적합한 패턴에 관심이 있습니다.

Answer 1

필자는 테이블 그룹을 자신의 데이터베이스로 옮겨야 할 필요는 없습니다. 시스템을 더욱 복잡하게 만들면 여러 데이터베이스의 백업을 동기화하는 것과 같은 추가 문제가 생깁니다. IMO 100 테이블은 다루기 힘들지 않습니다.

그러나 시스템 (데이터베이스)의 기능을 여러 시스템으로 나눠서 비즈니스를해야 할 필요가 있다면 꼭 그렇게해야합니다. 분명히 이것은 시스템의 주요 변경이나 심지어 재 작성을 필요로 할 것입니다.

Re : Waybill, Invoice 등 불행히도 MySQL은 다른 RDMS의 MS SQL Server와 마찬가지로 Schema을 구현하지 않습니다. 테이블에 접두어 (PaperWaybill, PaperInvoice 등)를 추가하여 스키마 고유의 네임 스페이스를 시뮬레이트 할 수 있습니다.

그러나 시스템을 7 년 동안 사용해 본 결과, 테이블 이름을 변경하는 것이 좋지 않을 수 있습니다. 모든 종속성 문제는 까다로울 수 있습니다. 이 테이블을 모두 액세스하는 여러 응용 프로그램, 보고서, 작업 등이있을 수 있습니다.

IMO 왜 그렇게 관계가 적은지 핵심 이유에 대해 알아야합니다. 관계가 존재할 수도 있지만 FOREIGN KEYS은 삭제되었습니다. performance reasons입니다. 이것이 시스템을 다이어그램으로 표시하는 기능을 방해하거나 ORM 코드 생성기와 같은 도구가 관계를 만들지 못하게하는 경우 PROD 데이터베이스를 DEV 환경으로 복원하고 DEV에 외래 키를 다시 추가 할 수 있습니다. 동시에 데이터 품질에 대한 아이디어를 얻을 수 있습니다. FK 제약.