레일 및 여러 데이터베이스 연결에서 루비를 많이 읽은 후, 나는 많은 사람들이하지 않는 것을 발견했습니다. 적어도 roror에서는 그렇지 않습니다. 많은 다른 데이터베이스와 스키마를 쿼리하고 보고서 또는 하나의 완벽한 페이지에 대한 정보를 가져 오는 데 익숙합니다. 따라서 사용자는 여러 다른 시스템에 로그온 할 필요가 없습니다. 하나 또는 두 개의 웹 페이지에 모든 시스템이있는 페이지를 만들 수 있습니다.하나 이상의 데이터베이스를 쿼리하는 유일한 사람입니까?
웹 및 데이터베이스 기반 디자인에서 일반적인 경우가 아닙니까?
편집 : 내 원본 코드가 대부분 고전 ASP에 있기 때문에 편집 할 수 있습니까?
나는 정말로 솔직히 대부분의 ORM 디자이너가 사용자가 하나 이상의 데이터베이스에 액세스하려고한다고 생각하지 않는다고 생각합니다. 이것은 ORM 우주에서 꽤 일반적인 한계로 보인다.
매우 제한적이고 실망스러운 것처럼 보입니다. – johnny
두 데이터베이스에서 데이터를 가져 와서 보고서를 컴파일하는 것은 드문 일은 아니지만 데이터베이스의 쿼리 엔진에서 최적화 할 수 없기 때문에 일반적으로 OLTP 시스템은 단일 데이터베이스를 사용하여 응용 프로그램을 계속 실행합니다.
응용 프로그램의 워크 플로의 단일 부분에서 여러 데이터베이스를 사용하는 경우는 드뭅니다. 그러나 모든 사례에서이 작업은 여러 웹 서비스 호출을 통해 수행되었습니다.이 호출은 문제의 데이터베이스를 감싸는 여러 가지 항목으로 이루어집니다.
필자는 필자가 알고있는 한 번에 여러 데이터베이스를 직접적으로 조회하고 결과를 단일 보고서로 병합 할 필요가 없었습니다.
와우. 나는 그렇게하지 않는다고 상상할 수 없다. – johnny
나는 이것을한다. 인증 서비스는 하나의 db를 사용하고 다른 db를 사용하는 응용 프로그램이 액세스합니다. +1하지만 동일한 응용 프로그램에서 직접 두 데이터베이스에 액세스하는 것을 피하려고합니다. 일부 리팩토링을 고려해야한다는 것은 꽤 좋은 지표입니다. –
@ johnny 왜 그래? 어쨌든 웹 서비스에서 데이터 레이어를 랩핑하는 것은 꽤 일반적입니다 (.NET 개발에서는). 티어의 명확한 분리 이외의 다른 이유로 (TCP 또는 파이프 엔드 포인트의 경우 성능상의 차이는 무시할 만하다). – Dusda
고객 웹 사이트는 3 개의 데이터베이스에서 실행되므로이 작업을 수행합니다. 실제로, 저는 모든 것을 하나의 중앙 데이터베이스에서 뷰로 집어 넣고 다른 뷰와 연결합니다.
나는 이것을 "정상적인"행동이라고 결코 생각하지 않았습니다. 나는 대부분의 시간 동안 당신이 한 시스템을 설계하고 그것을 반대 할 것이라고 생각합니다.
편집 : 정교하게하기 위해 Linq to SQL을 데이터 계층에 사용하고 데이터베이스 뷰에 대해 개체를 정의합니다. 이렇게하면 동일한 데이터 모델에서 작동하는 보고서와 응용 프로그램 코드를 유지할 수 있습니다. 당신이 수동으로 기본 키를 정의하고 연관을 설정해야하기 때문에 Linq 엔티티를 설정하는 몇 가지 추가 작업이 있습니다 ... 그러나 지금까지 그것은 확실히 가치가 입증되었습니다. 우리는 Entity Framework에서 그렇게하려고 시도했지만 관계를 적절하게 설정하는 데 많은 어려움을 겪었으며 포기해야했습니다. 재미있는 점은 Entity Framework가 우리와 같은보다 고급 시나리오를 위해 설계된 것으로 생각된다는 것입니다 ...
ORM의 경우 다소 어려울 수 있습니다. 그러나, 그것을 할 수 있습니다. 필요에 따라 다양한 데이터베이스에서 개체를 가져온 다음이를 복합으로 사용하여 원하는 실제 개체 인 새 개체를 만듭니다. 프로세스의 ORM 부분을 건너 뛸 수 있으면 직접 데이터베이스를 쿼리하고 개체를 직접 빌드 할 수 있습니다.
기업 포털 (다른 데이터 소스를 통해 많은 데이터를 가져온)에서 이러한 종류의 아키텍처를 보았습니다. 포털의 요점은 사일로 시스템을 하나로 묶는 것입니다. 사용자는 많은 시스템을 개별적으로 사용하고 싶지 않을 수 있습니다 (특히 각 시스템에 로그인해야하는 경우). 이런 종류의 시나리오에서는 일반적으로, 특히 빠르게 확장되고 많은 수의 이종 시스템이있는 대기업이라면 정상입니다.
이 작업이 올바른지 여부는이 분리 된 DB가있는 이유에 따라 다릅니다.
당신이 지정한 이유 때문에 나는 그것들을 가지고있다. 다른 시스템이 많고 아무도 말할 수 없다면 말하지 않는다. 데이터를 표현하는 것은 나에게 달려있다. net, asp, odbc, sql 문 (테이블 어댑터를 통해). 아직은 간단하지 않다. – johnny
WebSphere Portal에 대해 읽었을 때, 다음과 같은 기능성 제품을 달성하고있는 것을 볼 수있을 것이다. http://www.ibm.com/developerworks/websphere/zones/portal/newto/ (WebSphere Portal로 전환하라는 제안은 아니며 Enterprise Resources의 Aggregator 예제로 사용하기 만하면 됨) – RichardOD
감사. 나는 그것을 알고 있지만 그것을 사용하고 싶지 않았다. 큰돈과 학습 곡선이 매우 높아 보였다. 아마 맞는 것 같지만 지금은 사용할 수 없습니다. – johnny
처음부터 시스템을 빌드하는 경우에는 이렇게하지 않는 것이 좋습니다. 설계하지 않은 시스템으로 작업하는 경우 선택의 여지가 많지 않으며 흔히 "유기적"및 "계획적"성장의 차이점이 있습니다.
master과 다양한 테스트 인스턴스를 제외하고 나는 9 개의 데이터베이스를 정기적으로 조회했습니다. 예, 저는 그것을 계승했으며, 그렇습니다. "클래식"ASP 수치가 눈에 띄게 나타납니다. 물론,이 엉망진창의 모든 "빛나는"디자이너는 오래 전에 사라졌습니다. 우리는 우리가 안전하게 할 수있는 한 빨리 그것을 더 정상적으로 바꿀 것입니다.
새로운 시스템을 구축하고 데이터베이스를 계속 추가하고 2 ~ 3 개의 데이터베이스를 사용한다면 디자인을 다시 생각해 볼 때입니다. OTOH, 여러 이질적인 시스템의 데이터를 집계하는 경우라면, 이상하지 않습니다. 필요로하는 시간과 문제에 따른 하드웨어 비용에 따라 데이터가 거의 정적 인 경우 주기적으로 Live 서버에서 데이터를 가져 오는 "보고 서버"에 대한 좋은 시나리오가 될 것입니다.
아니요, 나도 그렇습니다! –
검색을 시작했을 때 나는 전례가없는 뭔가를하고 있다고 생각할 것입니다. 나는 다른 프레임 워크 (ASP 또는 PHP 프레임 워크를 호출하는 경우)에서 너무 단순한 작업을 수행하는 것이 얼마나 힘든 일인지 믿을 수 없었다. – johnny