동의어를 사용하여 중복 테이블을 만들지 않는 것이 좋습니다.

정확히 같은 데이터베이스의 사본 3 개가 있습니다. 3 개의 데이터베이스 모두에 Users테이블이 있으며 사용자는 항상 동일한 설정으로 3 개의 데이터베이스 모두에 존재합니다. 사용자를 추가하거나 편집 할 때마다 3 개의 데이터베이스를 업데이트해야합니다.

Users데이터베이스 2 및 3에서 테이블 을 삭제하고 Synonym데이터베이스 1을 가리키는 테이블로 바꾸는 것이 더 좋은 아이디어 입니까?

내가 생각할 수있는 장단점은 다음과 같습니다.

찬성

• 더 쉬운 정비. 3 대신 한 위치에서 사용자를 업데이트 할 수 있습니다
• 사용자 ID는 데이터베이스간에 일치합니다 (많은 애드온 앱이 UserId를 기반으로하기 때문에 중요합니다)

단점

• 이것이 표준 절차라고 생각하지 않으므로 혼란 스러울 수 있습니다.
• 사용자는 데이터베이스간에 동일한 설정을 가져야합니다
• ( 아래 의 gbn의 답변에서 ) 데이터베이스 1이 다운되면 데이터베이스 2 및 3도 사용할 수 없습니다. 또한 복원시 데이터가 일치하지 않을 수있는 잠재적 인 문제가 있습니다.

이것은 테이블뿐만 아니라 데이터베이스간에 동일한 설정을 포함하는 몇 가지 다른 테이블에 대해 고려중인 옵션 Users입니다. 이해하기 쉽기 때문에 예제에서 Users를 사용하고 있습니다.

동일한 사용자를 가진 3 개의 데이터베이스가있는 이유는 무엇입니까?

하나의 데이터베이스가 다운되면 어떻게됩니까?

다른 두 데이터베이스의 사용을 방해하는 사용자 소스 데이터베이스의 단점이 들리는 것처럼 큰 문제는 아닐 수 있기 때문에 이러한 질문을하고 있습니다.

또한 데이터베이스가 다운되면 해당 기간 동안 다른 두 DB에서 사용자를 수정하면 일관성 문제가 발생합니다. 나는 우리가 더 많은 상황없이 최선의 조언을 줄 수 있다고 생각하지 않습니다.

지금은 사용자를위한 네 번째 데이터베이스를 만들고 거기에서만 변경하고 다른 데이터베이스와 동기화합니다. 기본적으로 동일한 데이터를 세 곳에서 변경하여 이미 비정규 화되어 있으며 아마도 일관성 문제가있을 수 있습니다. 내결함성이 중요한 경우이 체계는 여전히 다중 입력 문제를 해결하면서이를 제공합니다.

기존 데이터베이스 중 하나를 사용하는 대신이 네 번째 사용자 / 설정 전용 데이터베이스를 사용하는 것이 좋은 전략이라고 생각합니다. 다른 리소스에 묶여 있거나 많이 사용되지 않기 때문에 다운 될 가능성이 적기 때문입니다. 나는 당신이 당신이 이것을 할 수 없다고 말한 것을 알지만, 왜 그런지는 확실하지 않습니다. 기본 데이터베이스의 응용 프로그램이 사용자 편집을 직접 지원합니까, 아니면 사용자가 다른 곳을 가리킬 수있는 완전히 별개의 기능을 편집하고 있습니까?

사실, 동의어를 사용하든 데이터를 동기화하든이 "정식 사용자 테이블"아이디어를 사용하면 다운 사용자 DB 중에는 사용자를 수정할 수 없지만 괜찮습니다. 문제를 해결하고 제기하십시오! 하나의 소스, 하나의 편집 장소, 깨진 경우 고칠 것. 동기화를 사용하면 다른 모든 데이터베이스에는 작업 할 수있는 임시 복사본이 있지만 편집 할 수는 없습니다. 시스템 전체에서 데이터 복제를 최소화하는 것이 훌륭하고 유용한 목표입니다. 세 곳에서 동일한 데이터를 입력하는 것은 심각한 문제이므로이를 제거하기 위해 가능한 모든 조치를 취하십시오.

더 많은 의견을 처리하려면 모든 응용 프로그램에서 사용자 ID가 다른 경우 두 개의 새 데이터베이스가 기본 데이터베이스와 동기화되도록 계획된 다운 시간을 신중하게 고려해야합니다 (아이디어가 필요한 경우 별도의 질문을하십시오) 이것을 달성하는 방법에 대해, 까다 롭지 만 실제로 그렇게 어렵지는 않습니다).

비즈니스 요구 사항을 분석하고 주 데이터베이스에 사용자 데이터가 올바른지 확인해야하는 경우에도 여전히 정식 데이터로 사용하고 동의어 또는 동기화 중에서 선택하여 계획되지 않은 중단 시간이 모든 데이터베이스에 미치는 영향을 해결하십시오.

동의어 사용의 또 다른 단점은 더 이상 각 데이터베이스의 사용자에게 적절한 FK를 가질 수 없다는 것입니다.

누락 된 "Con"

복원시, 사용자가 동의어의 대상 데이터베이스에 존재하지 않을 수 있습니다. 손상되었다고 말하면 백업에서 복원해야합니다.

즉, 동의어를 사용하면 실제 데이터베이스에서는 참조 할 수없는 데이터베이스 간 참조 무결성을 가정하게됩니다.

이것의 또 다른 결과는 이것을 복구하려고 할 때 일치하지 않는 사용자 ID입니다. (복원 후 사용자를 추가하여). 그러나 이것은 내가 언급 한 데이터베이스 간 참조 무결성으로 인해 절대 가정해서는 안됩니다.

그러지 마 ..

dba.se에 대한 관련 답변 : 복원 후 "데이터베이스 간 참조 무결성"에 대한 비 dbo 스키마 사용 시점과 새 데이터베이스 사용시기 결정 기준

데이터베이스 플랫폼에 따라 다른 옵션은 데이터베이스 2 및 3에서 테이블을 삭제하고 데이터베이스 1에서 테이블의 구체화 된보기 로 바꾸는 것입니다 .

찬성

• 손쉬운 유지 보수 (데이터)
• 일치하는 ID
• 중단은 다른 데이터베이스에 영향을 미치지 않습니다 (적어도 변경이 필요할 때까지)
• 모든 데이터베이스를 사용하여 테이블을 복구 할 수 있습니다.

단점

• 데이터는 새로 고침 일정만큼 최신입니다.
• 테이블 정의가 변경되면 구체화 된보기도 변경해야합니다.

또한 조회 빈도, 새로 고침 빈도 및 데이터 변경 빈도에 따라 동의어 솔루션보다 더 많은로드가 발생하거나 발생하지 않을 수 있습니다.

업데이트 : FrustratedWithFormsDesigner의 의견은 본질적으로 구체화 된 뷰를 수행 할 수없는 플랫폼을위한 구체화 된 뷰입니다. 스크립트를 사용하여 테이블을 주기적으로 동기화 할 수 있습니다. 하나의 데이터베이스가 마스터로 지정된 경우 모든 스크립트가이를 기반으로 변경을 수행 할 수 있습니다. 이것은 구체화 된 관점의 모든 장단점이 있습니다. 내장 기능을 이용할 수 없었습니다.

공유 된 사용자 정보를 저장하는 4 번째 DB를 만듭니다. 사용자 DB를 가리키는 각 기타 Dbs를 작성 Synonyms하거나 작성하십시오 Views.

마지막으로 해당 앱과 관련된 사용자 데이터를 보유하는 3 개의 기존 데이터베이스 각각에 확장 테이블 ( 'UserDB.Usertable'과 일대일 관계가있는 테이블)을 만듭니다.

편집 : 아래 의견을 바탕으로

이 경우 첫 번째 db를 마스터 사용자 테이블로 사용하십시오. Synonyms및 기타 Dbs 각각의 확장 테이블.

중요 사항 :이 방법을 사용하면 첫 번째 앱이 다운되면 다른 두 앱이 다운됩니다! 모든 사람이이 단점을 이해하도록하십시오.