여러 계정을 처리하기 위한 데이터베이스 구조(Multi-Tenant Data Architecture)?

Question

단일 엔터티를 처리하는 소프트웨어를 작성하는 것은 항상 쉽습니다. 그러나 여러 계정/회사를 처리하기 위한 소프트웨어를 설계하려면 실사가 필요합니다.

저는 현재 여러 계정/회사를 처리하는 데이터베이스 스키마에 대한 초기 연구를 수행하고 있는데, 적절한 스키마를 보여주는 웹 페이지나 오픈 소스 소프트웨어를 공유할 수 있는지 묻고 있습니다.

편집하다:이에 대한 적절한 용어인 Multi-Tenant Data Architecture를 찾을 수 있었습니다. 접근 방식을 설명하는 유용한 Microsoft 기사:http://msdn.microsoft.com/en-us/library/aa479086.aspx

감사해요.

Answer 1

이는 "단일 엔터티"보다 약간 더 복잡합니다. 최악의 경우, 즉 여러 회사가 각각 여러 계정을 가지고 있다고 가정해 보겠습니다. 회사용 테이블 1개. 회사 ID의 외래 키가 있는 계정에 대한 테이블 1개. 그런 다음 각 거래에는 계정 ID의 외래 키가 있습니다. 다른 모든 데이터의 경우 해당 데이터가 하나의 회사, 하나의 계정 또는 다른 데이터에 속하는지 결정해야 합니다. 즉 직원은 일반적으로 하나의 회사에서만 일할 수 있으므로 직원은 회사 ID를 외래 키로 갖습니다. 부서는 한 회사, 동일한 관계에 속합니다.

무엇이 누구의 것인지 이해하고 관계를 구축하는 것이 전부입니다. 그것은 매우 단순하게 들릴지 모르지만 실제로는 그게 전부입니다.

일부 확립된 스키마를 사용하려고 하면 많은 노력을 절약할 수 있지만 그러한 노력이 좋은 결과를 보장합니다. 좋은 데이터베이스 디자인은 "한 직원이 두 개 이상의 부서에서 일할 수 있습니까?"라는 모든 질문에서 비롯됩니다. "구매 비용은 항상 한 부서에 청구되나요, 아니면 비용을 분산할 수 있나요?" "직원 재배치에 대한 승인을 두 번 이상 추적해야 합니까?" 이는 영원히 계속되지만 그렇게 하지 않으면 시스템은 끊임없이 사용자를 실망시키고 끝없는 수정이 필요할 것입니다.