블로그 및 기사를 검색했지만이 시나리오에 대한 많은 지원을 찾지 못했습니다. 나는 EF를 파고 들며 여러 데이터베이스의 데이터를 포함하는 뷰를 생성 한 다음 해당 뷰에서 EF 객체 모델을 만들 수 있음을 깨달았다. 그것은 작동하지만, 성능, 확장 성, 유지 보수의 일반적인 문제에 대해 잘 모르겠습니다. 데이터베이스 간의 연결을 달성하는 방법은 EF 모델에 연관을 만드는 것입니다.하나의 SQLServer 인스턴스에서 여러 DB간에 EF를 사용할 수 있습니까?
누구든지 이러한 유형의 구현에 대한 정보를 갖고 있습니까? 이 제안 된 솔루션에 대한 또 다른 솔루션이나 주석이 있습니까?
덕분에, 여러 데이터베이스에서 데이터를 기반으로 모든 하나의 데이터베이스에서보기 만들기에 관해서
톰, 나는 동일한 데이터베이스에있는 모든 데 비해 특정 성능 차이를 보지 못했다.
가장 큰 직접적인 영향은 보안입니다. 연결을 허용하지 않는다고 가정하면 사용자는 데이터베이스 간보기가 작동하는 수준의 기본 데이터베이스 간 개체에 대한 사용 권한을 가져야합니다 (예 : 최상위보기가 테이블을 참조하는 경우 테이블을 참조해야 함). 사용하는 열에 대한 적절한 선택,보기를 참조하는 경우에는보기에서 동일하지만 아래에있는 항목이 필요하지 않음) - 사용자로서 해당 데이터베이스에서 일부 역할이 허용되어야하며 권한이 있어야합니다 .
구조적으로 여러 데이터베이스에 특정 도전 과제와 제한 사항이 있으므로 유지 관리를 위해 그렇습니다. 별칭이 옵션 일 수 있습니다.
분명히 SQL Server의 확장성에 대해서는 확장 성이 없다고 가정하면 (일반적인 SQL Server 경로의 정상입니다) 이제는 각 데이터베이스가 실제로 두 데이터베이스가 되었기 때문에 샤딩에 어려움을 겪을 것입니다. 또는 여러 데이터베이스가 연결된 서버를 통해 하나의 중앙 데이터베이스에 연결됩니다. 특히 빛에 대한 접근이 통제되지 않으면 확장 성이 좋지 않습니다. 또는 각 인스턴스에서 복제 된 데이터베이스에 합류하는 여러 데이터베이스가 옵션 일 수 있습니다. 그것은 모두 귀하의 도메인 및 데이터 문제에 달려 있습니다. 많은 가능성이 있습니다.
그래서 통합은 확장이 필요할 것으로 예상 될 때 옵션이 될 수 있으며 데이터베이스 내에서 별도의 스키마를 사용하는 것이 옵션 일 수 있습니다. 이제 뷰로 시작한 다음 데이터가 단일 데이터베이스로 이동하면 더 이상 뷰가 데이터베이스를 통과하지 않게됩니다.
또한 다른 데이터베이스의 개체를 기반으로하는 개체에 대해서는 SCHEMABINDING을 보장 할 수 없습니다.