여러 DB를 하나의 DB로 병합하려면 어떻게해야합니까?

Question

저는 6 개의 DB로 작업하고 있습니다. DB는 모두 동일한 스키마, 동일한 SP 등을 가지고 있습니다. 처음에는 DB를 설계 한 사람에게 말하면 많은 DB를 사용하려는 동기의 상당 부분이 효율성이었습니다. 다른 대안은 데이터베이스의 거의 모든 테이블과 sp에 열을 추가하여 어떤 데이터 세트가 작업 중인지를 표시하는 것입니다. 이로 인해 여러 samll DB 대신 하나의 거대한 (따라서 느린) DB가 생성됩니다. 쿼리되는 데이터 집합을 나타내는 열 대신에 연결 문자열을 사용하여 어느 데이터베이스가 적중했는지 선택합니다.

정말이 조직을 싫어하는 유일한 이유는 코드 중복이 많아서 유지 관리에 어려움이 있다는 것입니다. 예를 들어, 저장 프로 시저를 변경하고자 할 때마다 모든 데이터베이스에서 alter 문을 실행해야합니다.

내가 고려한 한 가지 해결책은 모든 데이터를 하나의 큰 데이터베이스로 결합하여 장소에 여분의 열을 추가하여 데이터를 결합하지 않은 경우 데이터를 나타냅니다. 그런 다음이 열의 값으로 모든 테이블을 분할 할 수 있습니다. 이론적으로이 모든 결과는 모든 데이터 자체의 기본 표현이 현재와 도덕적으로 동일하지만 인덱스, 스키마, SP 등에 중복되지 않는다는 것입니다.

내 질문 이것들 :

1. 이것은 좋은 아이디어입니까? 이 작업을 수행하는 더 좋은 방법이 있습니까?
2. 이렇게하는 데 문제가 있습니까?
3. 성능에 영향을 미칩니 까?

Answer 1

누구나 어느 시점에서이를 처리 할 것입니다. 내 개인적인 견해는 여러 데이터베이스가 뒷면의 고통이며 더 빠르지 않다는 것입니다. 유지 관리의 골치 아픔 때문에 통증이 있습니다. 필요에 따라 각 테이블에 추가 열을 추가해도 인덱싱이 제대로 설정되면 프로세스가 많이 느려지지는 않습니다. 유지 관리가 훨씬 쉬워집니다. 또한 여러 DB에서 트랜잭션을 수행하는 것은 번거롭고 MTC가 필요합니다.

현재 하나의 데이터베이스를 사용하는 것이 종종 멀티 테넌트 데이터베이스라고합니다. 이것을 조금 연구하고 싶을 수도 있습니다. 하지만 가능한 한 여러 개의 DB를 피할 것입니다.

Answer 2

나는 Randy와 다른 생각이 듭니다.

멀티 테넌트 모델은 장점이 있습니다.

데이터베이스가 5 개이든 500 개이든 관계없이 유지 관리가 크게 다르지는 않습니다. 어느 시점에서 개별 데이터베이스의 유지 관리를 살펴보고 해당 세트를 살펴보십시오. 예, 백업을 직렬화해야하며 모든 데이터베이스에서 인덱스 재구성/재 작성을 한 번에 수행 할 수 없습니다.

더 많거나 적은 동일한 데이터베이스 전체에서 코드를 변경하는 경우 여분의 손가락을 들지 않고 여러 데이터베이스에서 많은 작업을 스크립트로 작성하는 쉬운 방법이 있습니다. SQLFarms Combine (현재는 JNetDirect에서 판매)이라는 도구를 사용하지만, 사용하지 않은 RedGate MultiScript와 같은 다른 제품도 있습니다.

멀티 테넌트 모델에 대해 가장 좋아하는 점은 규모가 커지고 갑자기 새로운 데이터베이스 서버가 필요할 때 세입자 중 한 명 (예 : 가장 분주하거나 가장 빠르게 성장하는 곳)을 새 서버. 모든 사람이 동일한 데이터베이스에 끼어들 경우, 특히 다운 타임을 최소화해야하는 경우에는 데이터 만 추출하는 것이 매우 어려워집니다.다중 사용자 모델에서는 데이터베이스에 대한 미러링을 설정 한 다음 준비가되면 주 데이터베이스를 전환 할 수 있습니다.

Answer 3

나는 이러한 데이터베이스를 결합하는 편이 낫습니다. 두 번째 물리적 디스크의 추가 인덱싱, 분할, 클러스터링 등과 같은 매우 큰 데이터베이스의 잠재적 인 성능 저하를 설명하기 위해 SQL Server에 내장 된 다른 기능이 있습니다. 많은 다른 데이터베이스에 스키마 업데이트를 배포하는 데 관련된 두통과 오버 헤드 단일 데이터베이스에서 쉽게 처리 될 때 시간이 오래 걸릴 수 있습니다. SQL Server는 이러한 상황에서 실제로 확장 성이 좋습니다. 데이터베이스 서버에서 수행 할 작업을 수행하고 데이터에 대한 신속한 액세스를 제공합니다. 응용 프로그램 디자인에 중점을두고 SQL Server에 저장소 모델을 남길 수 있습니다.

또한 위에서 언급하지는 않았지만이 "많은 데이터베이스"모델을 사용하는 응용 프로그램에는 동적 SQL의 일부 레벨이 포함되어 있다고 생각됩니다. 알기 때문에 응용 프로그램이나 구성 파일에 하드 코딩 할 수는 없습니다. 즉, 연결 문자열이나 실제 SQL 문을 즉시 생성해야하며 이는 매우 큰 보안 위험이 될 수 있습니다 ("SQL 동적 SQL의 잠재적 인 위험성에 대해 잘 모르는 경우).