Oracle 객체가 얼마나 널리 사용됩니까?

Oracle 객체가 얼마나 널리 사용됩니까?

데이터베이스 클래스에 대한 과제를 작성하고 있는데, 기존 관계형 스키마를 Oracle 개체로 마이그레이션해야 합니다.이 모든 실패는 저를 궁금하게 했습니다. 이것들이 얼마나 널리 쓰이는지요?데이터 모델은 혼란스럽고 구문은 끔찍하며 객체 방향은 구현 방식의 약 4분의 3에 불과합니다.

이거 쓰는 사람 있어요?

우선 일부 표준 Oracle 기능에서는 유형(예: XMLDB 및 Spatial)(Nested Table 데이터 유형의 열 선언 포함)을 사용합니다.

또한 많은 PL/SQL 개발자가 PL/SQL 컬렉션 또는 파이프라인 기능을 선언하기 위해 항상 유형을 사용합니다.

그러나 Type을 광범위하게 사용하고 PL/SQL API를 구축하는 곳은 거의 없습니다.여기에는 몇 가지 이유가 있습니다.

1. Oracle은 Objects를 매우 느리게 구현했습니다.버전 8.0에 도입되었지만 9.2가 되어서야 상속, 다형성 및 사용자 정의 생성자를 완전히 지원했습니다.적절한 객체 지향 프로그래밍은 이러한 기능 없이는 불가능합니다.우리는 못 받았습니다.SUPER()버전 11g까지.도 TYPE BODY다의 선언과이 없습니다.
2. 그 구문은 종종 투박하거나 답답할 정도로 모호합니다.그 문서는 도움이 되지 않습니다.
3. Oracle과 함께 작업하는 대부분의 사람들은 관계형/절차형 프로그래밍 학교 출신인 경향이 있습니다.이는 OOP를 이해하지 못하거나, OOP가 데이터베이스 프로그래밍에서 유용한 부분을 이해하지 못하는 경향이 있음을 의미합니다.사람들이 깔끔한 아이디어를 떠올릴 때도 오라클의 구문을 사용하여 구현하는 것이 어렵거나 불가능하다고 생각합니다.

그 마지막 포인트가 핵심입니다.우리는 새로운 구문을 배울 수 있고 오라클을 설득하여 피쳐 세트를 완성할 수 있지만 Types에 대한 사용법을 생각해 낼 수 있는 경우에만 가치가 있습니다.그것은 상속과 다형성을 이용하여 해결할 수 있는 문제가 필요하다는 것을 의미합니다.

저는 활자를 많이 사용하는 시스템 하나를 작업한 적이 있습니다.데이터 웨어하우스 시스템이었고, 데이터 로딩 서브시스템은 Type으로 구축되었습니다.근본적인 근거는 간단했습니다.

• 로드하는 모든 테이블에 동일한 비즈니스 규칙 템플릿을 적용해야 하므로 프로세스가 일반적입니다.
• 모든 테이블에는 고유한 프로젝션이 있으므로 SQL 문은 각 테이블마다 고유합니다.

Type 구현은 깨끗합니다. 제네릭 프로세스는 Type에 정의됩니다. 각 테이블에 대한 구현은 해당 제네릭 Type에서 상속되는 Type에 정의됩니다.특정 유형은 메타데이터에서 생성할 수 있습니다.저는 몇 년 전 UKOUG에서 이 주제에 대해 발표했고, 제 블로그에 이 주제에 대해 더 자세히 적었습니다.자세히 알아보세요.

그런데, 관계론에는 도메인(Domains)의 개념이 포함되어 있는데, 도메인은 제약 조건 등을 포함하여 사용자가 정의한 데이터 유형입니다.RDBMS의 어떤 맛도 도메인을 실제로 지원하지 않지만 Oracle의 Type Implementation은 확실히 그 과정에서 한 단계입니다.

저는 그것의 이점을 본 적이 없습니다. 제가 마지막으로 검토했을 때, 당신의 객체 정의는 테이블에 의해 사용되면 불변이었기 때문입니다.

따라서 고객 테이블 정의에 사용한 주소 개체가 있다면 고객 테이블을 삭제하거나 매우 혼란스러운 변환을 거쳐야 주소 개체 정의를 변경할 수 있습니다.

애플리케이션이 하는 것과 같은 데이터 인스턴스화에는 개체가 문제가 없지만 데이터 저장 및 세트 기반 조작에는 문제가 없습니다.

다른 많은 답변들은 객체를 사용하는 것이 합리적인 예를 제시합니다. 일반적으로 이러한 예들은 특정한, 아마도 복잡한 유형의 데이터를 처리하기 위한 것입니다.Oracle 자체는 지리공간 데이터에 이를 사용합니다.

안타깝게도 일부 대학 과정에서 나타나는 것을 제외하고는 일반적으로 행해지지 않는 것은 일반적인 관계형 표 대신 객체 기반 표를 사용하여 직원이나 부서와 같은 일반적인 데이터를 저장하는 것입니다.

create type emp_t as object (empno number, ename varchar2(10), ...);
create table emp of emp_t;

이는 개념을 가르칠 수 있는 좋은 간단한 예가 될 수도 있지만, 저는 이 접근 방식이 "구식" 관계형 표보다 적합하고 현대적이며 따라서 더 낫다고 생각하는 새로운 세대의 데이터베이스 개발자로 이어질 수도 있다고 생각합니다.그것은 단호하게 그렇지 않습니다.

한 곳에서 사용한다는 얘기만 들었고, 관련 개발자들은 그로부터 벗어나기 위해 전환하고 있었습니다.순수하게 PL/SQL에 사용하려고 생각했지만, DBA가 테이블에서 사용할 수 있는 유형을 설치할 수 없도록 했기 때문에 이런 일은 없을 것 같습니다.

Share and enjoy.

It's not too uncommon to see them play a small role somewhere in your system. For example, if you're doing something with Oracle data cartridge. Some times when you need to do something really weird they are necessary.

It is uncommon to see them used extensively in a system. I've seen two different systems use a lot of objects and it was a disaster both times: difficult to use, very slow, and full of bugs.

"Simple" relational methods that use basic tables, rows, and columns are almost always good enough. Every programmer (and program) can understand these concepts, and they are powerful enough for almost any task. Yet you can spend many years trying to fully understand and optimize these methods. Object relational technology adds a huge amount of complexity on top of that for very little gain.

I've used simple types with constructors and a few methods to wrap some functionality of interacting with an existing tcp server. I needed to pass x bytes (raw object) and receive back x bytes (clean object). I could have written some procedure that was particular to my task, but using object type allowed this to be a bit more generic for others. Nothing fancy, very basic OO stuff, create the raw object, populate a handful of its 100 or so properties, call its clean function, and assign the result to a new "clean" object. Anyone else who wanted to call the tcp server could follow the same basic steps, only populating whatever raw values with their data.

Still, in my experience I wouldn't say Oracle is object oriented, but rather has some basic functionality of objects. And as others said, companies don't buy Oracle for it OO capabilities. Don't get too caught up in it with Oracle imo.

I would have to say it's not why people buy Oracle. It's very non-portable/non-standard, and as Adam pointed out has some usage pitfalls as well. I've not personally seen the benefit to it. I don't know how widespread it's usage is, but I can't imagine it's very big. Take a look around this site to see how many questions are asked about it. That may give you some insight.

실제로 사용해 본 적도 없고, 사용하는 사람도 들어본 적이 없으며, 널리 사용되지도 않습니다. 객체 지향 데이터베이스를 사용할 때는 Oracle이 OOO를 지원하지만 OO 데이터베이스는 아닙니다.OOO 데이터베이스에서 Oracle로 마이그레이션하는 사람들이 널리 사용한다고 생각합니다.

언급URL : https://stackoverflow.com/questions/5767200/how-widely-used-are-oracle-objects