여러 개의 데이터베이스, 적은 수의 테이블? 하나의 데이터베이스, 많은 테이블?

Question

최근 저는 IT 분야에서 일하고 있습니다. 제 전문 분야는 응용 프로그램 디자인이지만, 현재 데이터베이스 구조와 응용 프로그램을 수정하고 개조해야합니다.

현재 데이터베이스에는 20 개의 상호 연결된 데이터베이스가 있으며 수 백 개의 서로 다른 뷰에 수 백 (저장 프로 시저 없음)이 있습니다. 모든 것이 일련의 액세스 프론트 엔드에 묶여 있습니다.

이제 서버 아키텍처가 매우 이상합니다. 동일하거나 거의 동일한 데이터를 포함하는 여러 데이터베이스에 중복 테이블이 있으므로 분명히 많은 부분을 병합 할 수 있습니다. 그러나 이전 개발자가 응용 프로그램을 배치 한 방식은 테이블간에 전달해야하는 정보 중 SOME이 포함 된 "Shared_Tables"라는 다른 데이터베이스와 함께 모든 단일 응용 프로그램에 대해 별도의 데이터베이스를 갖는 것이 었습니다.

이제 기본적으로 회사의 새로운 시스템 구조를 만드는 것이 처음부터 시작되었으므로 분리 된 데이터베이스를 사용하는 것이 실제적인 이점이 있습니까, 아니면 모든 것을 1 개의 데이터베이스로 병합하는 것이 효율적인지 그들은 모두 동일한 인스턴스에서 실행되고 있다고 가정합니다.

또한 주목할 가치가없는 데이터베이스는 기본 키, 고유 키, 외래 키 등이 없습니다. 그리고 여러 필드의 데이터 유형은 동일해야 할 때 서로 다릅니다.

Answer 1

나는 @ dean의 게시물에 동의합니다. 또한 데이터베이스 구조를 즉시 해킹하기 시작하는 권장 사항은 좋지 않습니다. 데이터베이스가 많고 테이블의 양이 많다면 성능 및 회귀 버그가 큰 문제가되는 것보다 더 많은 문제가 발생할 것입니다.

나는 다음과 같은 추천 :

1. 회사의 데이터베이스의 현재 상태에 대한 분석을 수행 (보이는 이미이 작업을 수행 한 것처럼). 문제가있는 곳을 정확하게 지적하고 그들이 이해하는 특수 용어로 관리자에게이를 전달하십시오. 즉, 이것들은 문제의 목록이며, 현재의 시스템을 고치는 데 수년이 걸릴 것입니다.
2. 현재와 미래의 요구 사항이 무엇인지 확인하십시오. 이 회사는 어디에서 IT 시스템을 사용하고 데이터 요구 사항은 무엇입니까? 그런 다음 현재 구조가 현재/미래 요구 사항을 처리/지원할 수 있는지 확인하십시오. 그렇지 않다면, 왜 이것을 할 수 없는지에 대한 증거를 뒷받침하십시오. 다시 이해할 수있는 특수 용어로 관리자에게 전달합니다.

위의 (1)과 (2)의 요점은 무엇입니까?요점은 IT 시스템의 역사에 대한 배경 지식이 없으며 자신감을 가지고 해킹을 시작한 것처럼 특히 프로젝트에서 언급하기에 테이블을 병합하는 것이 매우 어렵다는 것입니다. 당신은 최선의 방법은 신선한 것을 시작하는 것임을 당신의 관리자에게 확신시킬 필요가있다. 당신은 당신의 제안을 뒷받침 할 구체적인 증거가 필요하다. (나는 현재 데이터베이스 구조를 해킹하는 것보다는 처음부터 디자인 할 것이라고 가정한다.)

빈 종이에서 시작하여 현재와 미래의 요구 사항에 따라 적합한 시스템을 설계하는 것이 훨씬 낫습니다. 기존 구조를 분석해야하지만 새 데이터베이스 설계에 필요한 것만 취해야합니다. 행운을 빈다. 나는 그것이 도움이되기를 바란다!

Answer 2

잘못된 끝에서 문제가 다가오고 있습니다.

처음부터 다시 디자인 할 고급 스러움이 있다면 논리 데이터 디자인부터 시작하십시오. 데이터베이스를 정확성의 단위로 생각하십시오 (모든 제한 조건은 데이터베이스에 포함되며 모든 제한 조건이 true이어야합니다). 엔티티와 엔티티 간의 관계를 확인하십시오. 열쇠를 확인하십시오. 정리하고 정상화하십시오. 그 후에야 성능과 효율성에 대해 스스로를 걱정해야합니다. 더 나은 성능을 위해 아름다운 디자인을 변경하지 않을 것이라고 말하면서, 항상 단단한 데이터 모델로 시작해야합니다.

"얼마나 많은 데이터베이스"에 대한 대답은 거기에서 자연스럽게 이어질 것입니다.