저는 여러 사업부에 적용될 응용 프로그램을 개발하도록 요청 받았습니다. 응용 프로그램은 기본적으로 각 장치마다 동일하지만 기본 데이터베이스의 구조는 변경되지 않는 사소한 절차 차이가 있습니다. 비즈니스 단위당 하나의 데이터베이스를 사용해야합니까, 아니면 모든 단위에 대해 하나의 큰 데이터베이스를 사용해야합니까? 사업 단위는 완전히 별개입니다.하나의 큰 데이터베이스 또는 클라이언트 당 하나?
선호도는 클라이언트 당 하나의 데이터베이스에 대한 것입니다. 장점 : 클라이언트가 너무 커질 경우
, 그들은 이동이 쉽다 - 백업, 복원, 붐을 연결 문자열을 변경합니다. 데이터가 대규모 데이터베이스의 다른 사람들과 섞여있을 때 그렇게 해보십시오. 스키마와 파일 그룹을 사용하여 격리 할지라도 그것들을 이동하는 것은 떡 먹기가 아닙니다.
클라이언트의 데이터를 삭제할 때 삭제됩니다.
정의에 따르면 각 고객의 데이터가 분리되어 있습니다. 이것은 종종 원하는 것이며 때로는 필요가 될 수 있습니다. 때로는 법적 구속력을 지닙니다.
데이터베이스 내의 모든 코드가 더 간단합니다. 클라이언트의 스키마 (매개 변수화 할 수 없음)를 포함 할 필요가 없으며 테이블을 클라이언트를 나타내는 추가 열로 어지럽게 처리 할 필요가 없습니다 .
명의 많은 200 또는 500 데이터베이스를 관리하는 10 데이터베이스를 관리하는 것보다 훨씬 더 열심히이라고 주장합니다. 제 경험상 전혀 다르지 않습니다. 작업을 자동화하는 스크립트를 만들고, 인덱스 유지 관리 및 백업 작업을 비틀어 버립니다.
잠재적 인 단점은 인스턴스 당 4 자리 이상의 데이터베이스의 영역에 들어가서 여러 서버 (임계 값은 실제로 작업량과 하드웨어에 따라 다르기 때문에 숫자를 선택합니다). 시스템을 올바르게 구축한다면 두 번째 서버를 추가하고 새로운 데이터베이스를 설치하는 것이 매우 간단해야합니다. 다시 말하지만 앱은 각 클라이언트의 연결 문자열을 인식해야하며 다른 서버를 사용하여 수행하는 모든 작업은 연결 문자열이 가리키는 인스턴스를 변경합니다.
dba.SE에 대한 몇 가지 질문이 있습니다. 그들은 모두 SQL Server에 대한 아니지만 개념과 문제의 대부분은 보편적 :
https://dba.stackexchange.com/questions/7924/one-big-database-vs-several-smaller-ones
귀하의 질문은 디자인 질문입니다. 이에 응답하려면 빌드하려는 시스템의 요구 사항을 이해해야합니다. 기술적 관점에서 보면 SQL Server 또는 실제로 모든 데이터베이스가 두 시나리오 중 하나를 처리 할 수 있습니다.
다음은 몇 가지 사항입니다.
첫 번째 질문은 클라이언트가 데이터를 분리하는 방법입니다. 여러 비즈니스 단위의 데이터를 함께 사용하는 것이 합법적이지 않을 수 있습니다 (예 : 은행의 투자 측면 및 시장 분석 측면). 이러한 상황에서는 별도의 데이터베이스가 솔루션입니다.
다음 질문은 보안입니다.어떤 상황에서는 클라이언트가 자신의 데이터가 다른 클라이언트 데이터와 섞여 있다는 사실을 알고 매우 불편할 수 있습니다. 작은 실수와 기밀 정보가 우연히 공유됩니다. 이는 같은 회사의 여러 사업부에서 문제가되지 않을 수도 있습니다.
다른 가동 시간 요구 사항, 업로드 요구 사항, 사용자 정의 및 다른 도구와의 상호 작용을 처리해야합니까? 하나의 비즈니스 유닛이 다른 비즈니스 유닛이 관심이 없다는 것을 고려하여 커스터마이즈가 필요하다면 다른 데이터베이스를 제안합니다.
또 다른 고려 사항은 성능입니다. 이 응용 프로그램은 많은 비싼 자원을 사용합니까? 그렇다면 다른 데이터베이스 (잠재적으로 다른 서버)에서 응용 프로그램을 분할 할 수있는 것이 매우 바람직 할 수 있습니다.
반면에 많은 데이터가 공유되고 저장소가 실제로 동일한 기본 기능을 가진 중앙 저장소 인 경우 하나의 데이터베이스가 좋은 선택입니다.
고든 고마워, 내 고객은 완전히 다른 분야이지만 같은 분야에 있기 때문에 '별개이지만 동등한'데이터베이스가 답이라고 생각합니다. –
대단히 감사합니다. 아론, 내 생각을 거의 정확하게 반복했습니다. –