내가 일하는 곳에 ESB가 있습니다6 개의 서로 다른 응용 프로그램 (또는 “종료점”이라고 말해야 함)이 연결되어 있습니다. 이 6 개의 애플리케이션은 2 개의 데이터베이스 인스턴스에서 3 개의 서로 다른 Oracle 스키마와 함께 작동합니다. 이러한 응용 프로그램 중 일부는 관련이 있기 때문에가 아니라 외부 공급자가 데이터베이스 인프라를 관리하고 새 스키마를 얻는 데 시간이 오래 걸리기 때문에 동일한 스키마에 공존합니다 (물론 DBA 액세스 권한도 없음) … 한 시점에서 기존 스키마를 “임시”재사용하여 개발을 계속할 수있을 것으로 생각하는 데 실제로는 시간이 너무 오래 걸립니다. 데이터의 “분리”를 시행하기 위해 고객의 경우 테이블 이름 앞에 “CST_”가 붙습니다. 또한, 우리는 절대적인 변화가 불가능한 몇 가지 유효한 이유로 스키마를 사용해야합니다. 물론 항상 발생하는 것처럼 “임시”

우리의 다른 응용 프로그램은 각각의 데이터베이스 스키마에 연결하고 자체 PL / SQL 패키지와 함께 작동하며 응용 프로그램 도메인 외부의 테이블 / 데이터와 직접 상호 작용하는 것을 절대 금지합니다.

ESB에 연결된 애플리케이션 중 하나가 도메인 외부에서 정보를 필요로하는 경우 ESB의 관련 서비스를 호출하여 해당 정보가 실제로 동일한 스키마에있는 경우에도 이론적으로는 약간의 조인 명령문이 필요합니다. SQL 요청 중 하나입니다 .

우리는 애플리케이션 도메인을 다른 스키마 / 데이터베이스로 분할하고 ESB의 서비스가 발생할 때 여전히 올바르게 작동하도록하기 위해 그렇게합니다 (크리스마스가 곧 손가락을 고집하고 있습니다)

이제는 외부에서 이상하고 끔찍하게 보일 수 있지만 그 이유가 있으며 하나 이상의 데이터베이스가 그렇게 중요하지 않다는 것을 보여주기 위해이 구체적인 경험을 공유하고 싶었습니다. 잠깐만! , 여러 가지 이유로 (Scott Whitlock의 경우 +1, 백업에 대한 마지막 단락 및 mya가 문제를 일으킨다는 점을 참조하십시오.) 그러나 SOA 서비스가 제대로 설계되어있는 것이 중요합니다. DBA가 아닙니다. 궁극적으로 모든 데이터베이스는 “엔터프라이즈 데이터웨어 하우스”에 속합니다.

마지막으로 Scott Whitlock의 마지막 단락, 특히

분리 문제 때문에 테이블을 다른 물리적 데이터베이스로 분리하지는 않습니다.

정말 중요합니다. 이유가 없으면하지 마십시오.

답변