응용 프로그램 당 하나의 데이터베이스를 사용하거나 여러 응용 프로그램간에 단일 데이터베이스를 공유해야합니까?

동일한 소스의 데이터를 사용하는 응용 프로그램이 여러 개 있습니다. 모범 사례 (또는 장단점)는 다음과 같습니다.

• 여러 응용 프로그램이 공유하는 데이터베이스의 데이터를 그대로 둡니다.

  1. 하나의 데이터베이스 만 필요하므로 공간 절약
  2. 응용 프로그램마다 다른 쿼리 요구가 있으므로 인덱싱이 복잡해집니다.

• 앱별 데이터베이스로 매일 데이터 가져 오기

  1. 앱별 데이터베이스에 중복 된 데이터가 존재하므로 더 많은 공간을 사용합니다.
  2. 각 앱이 개별 요구에 집중할 수 있으므로 더 쉬운 인덱싱

다른 장단점을 생략했을 수도 있습니다. 작업장에서이 작업을 어떻게 수행합니까?

요즘에는 공간이 저렴하므로 응용 프로그램 당 하나의 데이터베이스를 사용하는 것이 좋습니다.

여러 응용 프로그램간에 하나의 데이터베이스를 공유하면 몇 가지 심각한 단점이 있습니다 .

• 동일한 데이터베이스를 사용하는 응용 프로그램이 많을수록 성능 병목 현상이 발생 하여로드를 원하는대로 쉽게 확장 할 수 없습니다 . SQL 데이터베이스는 실제로 확장되지 않습니다. 더 큰 기계를 구입할 수는 있지만 클러스터에서는 확장 성이 떨어집니다!

• 유지 관리 및 개발 비용이 증가 할 수 있음 : 응용 프로그램이 현재 작업에 적합하지 않지만 이미 존재하는 그대로 사용해야하는 데이터베이스 구조를 사용해야하는 경우 개발이 더 어렵습니다. 또한 한 응용 프로그램을 조정하면 다른 응용 프로그램에 부작용 이있을 수 있습니다 ( "왜 불필요한 트리거가 있습니까 ??!"/ "더 이상 해당 데이터가 필요하지 않습니다!"). 개발자가 모든 유스 케이스를 알지 못하거나 알 수없는 경우 단일 애플리케이션에 대해 하나의 데이터베이스로 이미 어려움을 겪고 있습니다.

• 관리가 어려워 짐 : 어떤 응용 프로그램에 어떤 개체가 속하는가? 혼돈이 일어나고 있습니다. 내 데이터를 어디에서 찾아야합니까? 어떤 사용자가 어떤 개체와 상호 작용할 수 있습니까? 누구에게 무엇을 부여 할 수 있습니까?

• 업그레이드 : 이를 사용하는 모든 응용 프로그램에서 가장 낮은 공통 분모 인 버전이 필요합니다. 이는 특정 애플리케이션이 강력한 기능을 사용할 수 없음을 의미합니다. 이전 버전을 사용해야합니다. 또한 개발 비용이 약간 증가합니다.

• 동시성 : 프로세스간에 시간적 종속성이 없음을 정말로 확신 할 수 있습니까? 한 응용 프로그램이 오래된 데이터를 수정하거나 다른 응용 프로그램에서 먼저 변경해야하는 데이터는 어떻게됩니까? 동일한 테이블에서 동시에 작업하는 다른 응용 프로그램은 어떻습니까?

이에 비해 데이터 가져 오기 / ETL 프로세스는 거의 항상 간단하고 간단합니다. 필요한만큼 데이터를로드하면 공간이 저렴합니다. 각 응용 프로그램의 확장 성을 독립적으로 설명하고, 필요에 따라 구조를 조정 및 조정하면 동시성 문제가 발생하지 않습니다. 부작용도 훨씬 쉽게 추적 할 수 있습니다.

편집 : @Saeed가 언급했듯이 일반적으로 사용 가능한 서비스에서 데이터 조작을 캡슐화 할 수 있으면 하나의 데이터베이스를 여러 응용 프로그램과 공유하는 것이 더 쉽다는 것을 지적하고 싶습니다. 원시 액세스가 필요하지 않으면 매우 좋은 접근 방식입니다.

비슷한 상황이 한 번있었습니다. 내 문제는 재고 관리, 조달 관리, 사용자 관리 (직원)를위한 3 개의 애플리케이션을 구축하는 것이 었습니다. 권장 사항은 응용 프로그램 당 데이터베이스를 물리적으로 중단하거나 응용 프로그램 당 물리적으로 연결하지 않는 것입니다. 오히려 IMHO 논리적 분리가 더 효과적입니다.

예를 들어, 직원 정보를 처리하기 위해 3 가지 응용 프로그램이 모두 필요했습니다. 재고 및 조달 시스템 모두 상품 및 재고 품목의 동일한 정보를 사용했습니다.

사용자 및 상품 정보를 저장하는 공유 데이터베이스를 작성했습니다. 그런 다음 그 위에 서비스 계층을 구축하고 다른 응용 프로그램에서 해당 서비스를 사용했습니다. 예를 들어 현재 회사에있는 모든 직원의 목록을 표시하려면 서비스와 같은 메소드 만 호출하면 GetOnWorkEmployees()됩니다.

또한 별도의 웹 응용 프로그램 인 사용자 및 상품과 상호 작용하기위한 공통 UI를 만들었습니다.

따라서 @Falcon이 지적한 것에 덧붙여 하나의 데이터베이스에서 응용 프로그램 간의 공통 기능을 중앙 집중화하면 이점을 얻을 수 있다고 생각합니다.

이러한 애플리케이션이 동일한 데이터 (예 : 동일한 제품 및 고객 목록)에서 작동하도록하려면 데이터베이스를 함께 유지하십시오. 데이터베이스를 분리하여 아무것도 얻지 못합니다. 그것은 순전히 '인간적인'문제입니다-서버의 디스크에 바이트가 있습니다. 1 개 또는 100 개의 데이터베이스인지는 상관하지 않습니다. 그러나 분할하면 데이터 동기화를 처리해야합니다. 가져온 인덱싱 문제는 실제 문제가 아닙니다. db가 분할 된 경우 인덱스를 유지 관리하는 데 동일한 시간을 소비합니다.

성능이 문제가되기 시작하면 DB를 여러 서버에 복제하여 균형을 맞 춥니 다.

현재 상황에서 절충 할 가치가있을 수도 있고 그렇지 않을 수도 있지만 단일 데이터베이스를 사용하면 데이터 무결성을 유지하는 것이 더 쉽습니다. MS SQL Server에서는 최소한 한 데이터베이스에서 다른 데이터베이스로 외래 키를 사용할 수 없습니다. 트리거를 사용하여 외래 키 동작을 시뮬레이션 할 수 있지만 특별히 우아하지는 않습니다.

또한 쓰기 작업이 수행 될 때 데이터의 로컬 사본을 작성하는 것은 위험 할 수 있습니다. AppA와 AppB에 모두 공유 데이터의 사본이 있고 AppA가이를 업데이트하더라도 AppB는 여전히 이전 데이터를 갖습니다. 또는 데이터를 동기화 상태로 유지하기 위해 트리거를 설정해야합니다.

한 번에 여러 웹 사이트가 생겨나면서 시간이 지남에 따라 인기를 얻었습니다. 이들은 호스팅 제공 업체가 각각 1Gb 스토리지 공간 만 허용했기 때문에 별도의 데이터베이스를 사용했습니다. 그러나! 이러한 모든 웹 사이트가 포함 된 서비스를 출시하자마자 이러한 웹 사이트간에 트랜잭션을 수행해야했으며이를 수행하는 가장 편리한 방법은 모든 것을 하나의 큰 데이터베이스로 확실히 옮기는 것입니다.

그래서 나는 데이터베이스 구조를 최적화하고 관련 부분을이 중앙 데이터베이스에 압착했지만 다른 것은 제외했습니다.

내 의견은 어떻게 든 OOP의 패러다임과 관련이 있습니다. 비슷한 데이터를 함께 저장해야하므로 다른 응용 프로그램을 구축하는 경우 다른 데이터베이스를 사용해야합니다.

위의 경우 공통 db를 사용하는 것은 피할 수 없었지만 공통 쿼리의 일부가 아닌 별도의 db로 일부 테이블을 분리했다는 것을 기억하십시오.

또한 분리 된 상태로 유지하면 백업하기가 쉬워지며 데이터 손실 가능성이 줄어 듭니다. 문제가 발생하여 응용 프로그램이 서로 방해하는 경우 데이터베이스가 엉망이되고 기본적으로 앱을 이러한 위험에 노출시키지 않으려 고합니다.

대체로 공통 쿼리에 대한 공통 데이터베이스를 유지 관리 할 수있을뿐만 아니라 각 응용 프로그램마다 하나씩 유지 관리 할 수도 있습니다.

애플리케이션 아키텍처에 대해 더 자세히 설명 할 수 있습니까?

데이터베이스가 트리거 또는 비즈니스 패키지 코드와 같은 응용 프로그램 논리없이 데이터 리포지토리처럼 작동하는 경우 단일 데이터베이스를 보유하고 모든 작업에 데이터베이스를 사용하는 서비스에 비즈니스 수준의 기능을 캡슐화하는 것이 좋습니다. 데이터베이스 스키마에 트리거 또는 코드가있는 경우 단일 데이터베이스를 사용하면 많은 문제가 발생할 수 있습니다.