현재 고객으로 회사로 등록 할 웹 응용 프로그램을 설계 중입니다. 각 회사마다 고유 한 사용자 집합이 있습니다. 내가 이것을 설계 할 때 어떤 접근 방식이 가장 효과적 일지 궁금해하고 있습니다. 하위 도메인을 사용하는 fogbugz 또는 basecamp와 같은 사이트가 표시됩니다. 하위 도메인이있는 경우 하위 도메인 당 데이터베이스 인스턴스가 있습니까? 나는 그것이 회사마다 데이터베이스 인스턴스를 가지고 있는지 또는 어떤 종류의 회사 테이블을 가져야하고 하나의 데이터베이스에서 회사 및 사용자 데이터/자격 증명을 모두 관리해야하는지 궁금합니다.여러 데이터베이스 인스턴스 또는 단일 인스턴스로 웹 응용 프로그램 빌드
어떤 접근 방식이 가장 좋습니까? 이 주제 (예 : 웹 또는 도서)에 대한 문헌이 있습니까?
미리 감사드립니다.
일부 사항은 의견이있을 수 있으며 귀하의 구현에 적합하지 않을 수 있으므로 귀하의 선택을 재고해야합니다.
말했다되는 것을 나는 이러한 이유를 들어, 하나의 데이터베이스 접근 방식을 생각 하는데요 :
유지 : 등록 '클라이언트'당 데이터베이스를 실행하는 경우, 당신은 매우 쉽게 상황 곳에 도달 할 것 앱의 스키마를 변경하거나 업그레이드 할 때 모든 단일 데이터베이스 인스턴스에 적용해야합니다. 이것은 어리석은, 빨리 얻을 것이다.
편리 : 당신은 분석 및 사용 통계, 또는 모든 데이터베이스를 관리하다 몇 가지 방법을 할 수 있습니다. 단일 데이터베이스를 쿼리하는 것은 모든 데이터베이스에 대해 동일한 쿼리를 집계하는 것이 비교적 쉽습니다. 이것은 확장되지 않습니다.
확장 성 * : 2에서 언급했듯이 클라이언트와 앱 전체에 관한 정보를 쿼리하려면 특별한 종류의 집계가 필요합니다. 앱이 커질수록 검색어는 더 복잡해집니다. 다른 문제는 한 고객이이 앱을 다른 앱보다 훨씬 많이 사용하는 경우 최적화를 위해 무엇을 권장할까요? 앱, 큰 고객의 데이터베이스 또는 작은 고객의 변경 한 내용을 잊지 않고 모든 데이터베이스에 복사해야합니다.
백업 : 덤프를 만들고 어딘가에두기 만하면 하나의 데이터베이스를 쉽게 백업 할 수 있습니다. 1000 개의 클라이언트를 확보하고 이제는 1000 개의 데이터베이스 덤프를 실행해야하며, 하나의 데이터베이스가 손상된 경우이를 식별 할 수있을 정도로 충분히 이름을 지정해야합니다. 이것이 일어 났는지 어떻게 알 수 있습니까? 데이터베이스 오류는 전체 앱과는 달리 특정 오류로 현지화됩니다.
UI : 사용자가 앱에 가입하거나 초대 받았으며 특정 클라이언트에 속합니다. 해당 사용자 계정을 클라이언트의 데이터베이스에 저장 하시겠습니까? 그렇다면 사용자가 암호를 변경하려고하거나 데이터를 전자 메일로 보낼 때 해당 데이터로 작업하는 문제에 대한 확장 성을 참조하십시오. 그렇다면 사용자에게 어떤 데이터베이스가 있는지 알려줌으로써 찾을 수있게합니까?
간체 : 클라이언트 당 데이터베이스가 있으며 하나만 사용하려고합니다. 중요한 것들을 깨지 않고 어떻게 그들을 하나로 합치십니까? 자동 증가 ID를 사용하면 기본 키 충돌이 발생합니다. 북마크 된 URL은 키를 재생성하기로 결정하면 중단됩니다. 테이블의 외부 키는 더 이상 올바른 레코드를 가리 키지 않습니다. 데이터 무결성이 떨어집니다.
사용자 정의 하위 도메인을 통해 제품을 제공하는 '화이트 라벨'서비스에 대해 언급합니다. 나는 이들이 어떻게 작동하는지 알지는 못하지만 하위 도메인은 DNS 영역 파일의 기본 CNAME 또는 A 레코드에 불과합니다. 이들을 추가하는 프로세스는 자동화 될 수 있으며 응용 프로그램의 디자인과 약간의 서버 구성은 이러한 하위 도메인을 올바른 계정 및 데이터에 연결하는 것을 처리 할 수 있습니다. 전체적으로는하지만,이 모든 문제를 다루는 당신이하고 선호 수있는 일이라는 것을 결정할 수
http://client.example.com
http://example.com/client
: 그들은 사이에 단지 URL이, 어쩌면 백엔드에 앱을 구분하지 않는 것. 그러나 이렇게함으로써 당신은 발에서 몸을 쏠 수 있으며, 잘 설계된 단일 데이터베이스 스키마와 잘 추상화 된 프론트 엔드를 만들면 훨씬 많은 것을 얻을 수 있다고 경고하십시오.
* @ xQbert는 여러 데이터베이스에서 확장 성의 가장 큰 이점을 언급합니다. 나는 다른면에 더 관심이 있음을 분명히하기 위해이 답을 수정했습니다.
매우 완벽한 답변을 주신 fuzzyDunlop에게 감사드립니다. 나는이 길을 향하여 무겁게 기울고 있었지만, 나 자신을 짐작하기 시작했다. 내가 올바른 방향으로 가고있는 것 같아. – ralph
각 옵션마다 장점이 있습니다. 별도의 데이터베이스는 패치/수정/업데이트에 대한 유지 관리가 많기 때문에 관리 부담이 커집니다. 그러나 이는 또한 데이터 분리가 쉽고 사용자를 다른 데이터베이스 서버로 쉽게 분할하여 확장 할 수 있음을 의미합니다. 최종 목표와 요구 사항이 무엇인지에 따라 달라집니다. 귀하의 질문에 대한 은색 총알이 없습니다. 모든 결정에는 두 가지 측면이 있으며, 그 중 일부는 실제로 50/50이며 선택하고 계속 진행합니다. 니즈 (NEEDS)가 무엇인지 평가하고 어떤 솔루션이 이러한 요구에 가장 잘 부합하는지 평가하십시오. – xQbert
그걸 두번째 xQbert. 예를 들어 우리가 구축하고있는 애플리케이션의 경우 비즈니스 사용자가 다른 사람들의 데이터를 볼 수 없도록하는 것이 매우 중요합니다. 단일 데이터베이스에 보관할 때 테스트에서 발견되지 않은 버그로 인해 세입자간에 누수가 발생할 위험이 항상 높습니다. – user3141326