객체 데이터베이스의 장점과 단점은 무엇입니까?

Question

객체 관계형 매퍼와 임피던스 불일치를 가장 효과적으로 방지하는 방법에 대한 많은 정보가 있습니다. 이 모든 정보는 객체 데이터베이스를 사용하는 경우 논란의 여지가 있는 것 같습니다.내 질문은 왜 이것이 더 자주 사용되지 않습니까?성능상의 이유 때문입니까, 아니면 객체 데이터베이스로 인해 데이터가 애플리케이션의 독점이 되었기 때문입니까, 아니면 다른 이유 때문입니까?

Answer 1

• 정통. 데이터베이스 관리자는 관계 개념을 알고 있습니다.그다지 많지는 않습니다.
• 성능. 관계형 데이터베이스는 확장성이 훨씬 뛰어난 것으로 입증되었습니다.
• 성숙함. SQL은 강력하고 오랫동안 개발된 언어입니다.
• 공급업체 지원. OODBMS의 경우보다 더 많은 자사(SQL 서버) 및 타사(관리 인터페이스, 매핑 및 기타 종류의 통합) 도구 중에서 선택할 수 있습니다.

당연히 객체 지향 모델이 더 친숙합니다. 개발자, 그리고 지적했듯이 ORM 중 하나를 아끼게 될 것입니다.그러나 지금까지는 관계형 모델이 더 실행 가능한 옵션임이 입증되었습니다.

최근 질문도 참조하세요. 객체 지향 및 관계형 데이터베이스.

Answer 2

나는 사용해왔다 db4o 이는 OODB이며 나열된 대부분의 단점을 해결합니다.

• 익숙함 - 프로그래머는 SQL보다 자신의 언어를 더 잘 알고 있습니다(기본 쿼리 참조).
• 성능 - 이는 매우 주관적이지만 살펴볼 수 있습니다. 폴 포지션
• 공급업체 지원 및 성숙도 - 시간이 지남에 따라 변경될 수 있음
• 동일한 프레임워크를 사용하지 않는 프로그램에서는 사용할 수 없습니다. - OODB 표준이 있으며 다음을 사용할 수 있습니다. 다양한 프레임워크
• 버전 관리는 아마도 좀 촌스러운 일일 것입니다. - 실제로 버전 관리는 더 쉽게!

내가 관심을 갖고 있는 장점은 다음과 같습니다.

• 기본 쿼리 - Db4o를 사용하면 정적 유형 언어로 쿼리를 작성할 수 있으므로 문자열을 잘못 입력하거나 런타임 시 누락된 데이터를 찾는 것에 대해 걱정할 필요가 없습니다.
• 사용 용이성 - 도메인 계층, 지속성 계층(매핑) 및 마지막으로 SQL 데이터베이스에서 비즈니스 논리를 정의하는 것은 확실히 DRY를 위반하는 것입니다.OODB를 사용하면 그것이 속한 도메인을 정의할 수 있습니다.

동의합니다. OODB는 갈 길이 멀지만 계속 가고 있습니다.그리고 OODB로 더 잘 해결되는 도메인 문제가 있습니다.

Answer 3

객체 데이터베이스에 대한 한 가지 반대 의견은 데이터와 코드 사이에 긴밀한 결합이 생성된다는 것입니다.특정 앱의 경우 이는 괜찮을 수 있지만 다른 앱의 경우에는 그렇지 않습니다.관계형 데이터베이스가 제공하는 좋은 점 중 하나는 데이터에 대한 다양한 보기를 제공할 수 있다는 것입니다.

테드 뉴워드 이것과 OODBMS에 대해 이것보다 훨씬 더 잘 설명합니다.

Answer 4

성능과는 아무런 관련이 없습니다.즉, 기본적으로 모든 애플리케이션은 OODB를 사용하면 더 나은 성능을 발휘할 것입니다.그러나 이로 인해 많은 DBA가 직장을 잃게 되거나 새로운 기술을 배워야 합니다.훨씬 더 많은 사람들이 데이터의 오류를 수정하면서 직장을 잃게 될 것입니다.그렇다고 해서 기존 회사에서 OODB가 인기를 끌 가능성은 낮습니다.Gavin은 완전히 단서가 없는 것 같습니다. 더 나은 링크는 다음과 같습니다. 교회

Answer 5

단점:

• 데이터 스토어에 액세스하기 위해 동일한 프레임 워크를 사용하지 않는 프로그램에서는 사용할 수 없으므로 기업 전반에 걸쳐 사용하기가 더 어려워집니다.

• 비 SQL 기반 데이터베이스에 온라인으로 제공되는 리소스가 적습니다

• 데이터베이스 유형에서 호환성이 없습니다 (모든 코드를 변경하지 않고는 다른 DB 제공 업체로 교체 할 수 없습니다).

• 버전싱은 아마도 약간의 암캐 일 것입니다.객체에 새 속성을 추가하는 것은 테이블에 새 열을 추가하는 것만 큼 쉽지 않다고 생각합니다.

Answer 6

쇠렌

말씀하신 이유는 모두 타당하지만 OODBMS의 문제는 논리적 데이터 모델에 있다고 봅니다.객체 모델(또는 70년대의 네트워크 모델)은 관계형 모델만큼 단순하지 않으므로 열등합니다.

Answer 7

jodonnel, 객체 데이터베이스를 사용하여 애플리케이션 코드를 데이터에 연결하는 방법을 모르겠습니다.리포지토리 패턴을 사용하여 OODB에서 애플리케이션을 추상화하고 올바르게 디자인한 경우 ORM 지원 SQL 데이터베이스로 대체할 수 있습니다.

OO 애플리케이션의 경우 OO 데이터베이스는 지속 개체에 더 자연스럽게 적합합니다.

아마도 사실은 데이터를 도메인 모델에 연결한다는 것이지만 그게 핵심입니다!

도메인 중심의 관점을 사용하여 데이터, 비즈니스 규칙 및 프로세스를 모두 단일한 방법으로 보는 것이 좋지 않을까요?

따라서 가장 큰 장점은 OODB가 가장 현대적인 엔터프라이즈 수준 객체 지향 소프트웨어 응용 프로그램의 설계 방식과 일치하므로 다른 (관계형) 설계를 사용하여 데이터 계층을 설계하기 위한 추가 노력이 없다는 것입니다.구축 및 유지 관리 비용이 저렴하고 대부분의 경우 일반적으로 성능이 향상됩니다.

단점은 전반적으로 성숙도와 수용력이 부족한 것 같아요...