다중 사이트 시스템을위한 데이터베이스 구조 - 데이터베이스 & PHP

Question

제가 작동하는 시스템은 다음과 같이 구성되어 있습니다. 내가 Joomla를 기본으로 사용할 계획이라면.

은 (www.a.com)는 B (www.b.com) 검색 포탈이 C (www.c.com) 예약을 검색하기 위해 사용자에게 허용한다.

x (www.x.com), y (www.y.com), z (www.z.com)은 사용자가 예약 한 호텔입니다.

• www.a.com의 사용자는에 예약을 검색 할 수 있습니다 www.x.com
• 만 www.x.에 예약을 검색 할 수 있습니다 www.b.com의 사용자 COM, www.y.com
• www.c.com의 사용자는 www.x.com, www.y.com, www.z.com

모두에있는 모든 예약을 검색 할 수 있습니다 a, b, c, x, y, z는 동일한 시스템을 실행합니다. 그러나 그들은 별도의 도메인을 가져야합니다. 따라서 내 발견과 연구 아키텍처에 따르면 API가 모든 데이터베이스 호출을 통합하는 위와 같아야합니다.

여기서는 단 6 개의 인스턴스 만 표시됩니다 (a, b, c, x, y, z). 서로 다른 검색 조합으로 최대 100 개가있을 수 있습니다.

내 문제,

전체 시스템에 대해 단일 데이터베이스를 유지해야합니까? 그렇다면 필요한 경우 하나의 인스턴스를 어떻게 분리 할 수 ​​있습니까? (EG : 시스템에서 www.a.com을 제거하거나 시스템에서 www.z.com을 제거하십시오)? mysql을 사용하고 있기 때문에 레코드 수 때문에 시스템에 부담이되지 않을까?

각 인스턴스에 대해 별도의 데이터베이스를 유지 관리하는 경우 어떻게 검색합니까? 필요한 기록을 하나로 통합하고 검색을 수행하려면 어떻게해야합니까?

위에서 언급 한 것보다 다른 데이터베이스 접근 방법이 있습니까?

Answer 1

당신이 말한 문제는 "멀티 테넌시"입니다. 해결하기는 상당히 까다로운 문제이지만 운 좋게도 다른 사람들은 useful approaches을 작성했습니다. 링크는 Microsoft에 있지만, 세부 사항을 제외한 대부분의 SQL 환경에 적용됩니다. 귀하의 경우

장단점은 다음과 같습니다 당신의 호텔에서 데이터는 하나의 스키마로

• 적합합니까? 그들의 "공석"기록에는 동일한 분야가 있는가?
• 몇 개의 호텔이 있습니까? 3 개의 분리 된 데이타베이스는 약간 다루기 쉽다; 30 아마되지 않습니다; 300은 확실히 아닙니다.
• 데이터베이스가 얼마나 커질까요? 얼마나 많은 공석 기록이 있습니까?
• 시간이 지남에 따라 데이터 구조가 변경 될 가능성은 얼마나 높습니까? 한 호텔이 다른 호텔에서하지 못하는 변화가 필요할 가능성은 얼마나됩니까?

관리와 개발이 훨씬 쉬우므로 "단일 데이터베이스"모델이 적합합니다. 단, 데이터가 합리적으로 스키마에서 동일하고 합리적인 성능으로 데이터를 쿼리 할 수 ​​있어야합니다. MySQL에 많은 레코드를 저장하는 것에 대해 걱정하지 않아도됩니다.

PortalHotelAccess

PortalID HotelID 
----------------- 
A   X 
B   X 
B   Y 
C   X 
C   Y 
C   Z 

: 당신이 조회 테이블에 "호텔" "포털"지도 것 같은 디자인에서

Answer 2

나는 두 가지 접근법을 제안 할 수있다. 선택해야하는 것은 전체 시스템에 대한 몇 가지 추가 정보에 따라 다릅니다. 사실, 주요 질문은 시스템이 소비자 관점 (a, b, c 등)에서 데이터 제공자 (x, y, z 등)를 사칭 (법적으로 의미를 부여하여 대체) 할 수 있는지 여부입니다. .

중앙 DB

먼저 하나 실제로는 중앙 집중화 된 API를 사용하여 원래의 계획을 기반으로합니다. 단일 검색 엔진을 의미하며 데이터 원본에서 필요한 데이터를 수집하고 자체 DB에 집계하며 데이터 창작자에게 제공합니다.

이것은 데이터 소스가 데이터 표현이 다르면 가장 좋은 해결책 일 수 있으므로 일관성을 위해 사전 처리해야합니다. 또한이 변종은 고객이 연결 문제를 일으킬 수있는 가능성을 막아줍니다. 즉, 소스 사이트 중 하나가 짧은 기간 동안 오프라인 상태가되는 경우 (예약 서비스의 실제 성과에 큰 영향을주지 않고도 최대 몇 시간까지 걸릴 수 있음) 오프라인 사이트에 대한 요청을 처리하고 문제가 해결 될 때까지 모든 새 문서를 중앙 DB에 저장합니다. 반면에, 이것은 DB와 모든 데이터 소스 사이트간에 일종의 양방향 동기화를 제공해야한다는 것을 의미합니다.또한 중앙 DB는 처음부터 신뢰성을 염두에두고 작성되어야하므로 분산되어야합니다 (서로 다른 데이터 센터에 설치하는 것이 좋습니다).

이 방법은 아마도 최상의 사용자 경험을 제공 할 것이지만 강력한 구현을 위해서는 충분한 노력이 필요할 것입니다. 여러 로컬 DB를

모든 데이터 공급자가 자신의 DB를 실행하지만 (백엔드 API를 포함) 모두가 하나의 표준을 기반으로하는 경우

, 당신은 중앙 DB에 데이터를 복사 할 필요가 없습니다 수 있습니다 . 물론 중심점은 그대로 있어야하지만 DB가없는 중간 계층 로직 만 호스팅합니다. 이 레이어는 실제로 (x, y, z)를 적절한 (a, b, c)와 바인딩하는 API입니다. 모든 소비자 사이트는 적절한 설정이 포함 된 중앙 지점에서로드 된 위젯 (자바 스크립트 또는 완전한 웹 응용 프로그램 일 수 있음)을 호스팅합니다.

위젯은 지정된 모든 백엔드를 직접 요청하고 그 결과를 단일 목록에 집계합니다.

이 변형은 오늘날 대부분의 웹 응용 프로그램과 비슷하지만 구현이 더 간단하지만 오류가 발생하기 쉽습니다.