手始めに、一部の標準的なOracle機能はTypesを使用します。たとえば、XMLDBやSpatial（ネストされたテーブルのデータ型の列の宣言を含む）です。
また、多くのPL / SQL開発者は、PL/SQLコレクションまたはパイプライン関数を宣言するために常に型を使用します。
しかし、Typesを広範囲に使用し、それらからPL /SQLAPIを構築する場所はほとんどないことに同意します。これにはいくつかの理由があります。
- Oracleのオブジェクトの実装は非常に遅いです。それらはバージョン8.0で導入されましたが、継承、ポリモーフィズム、およびユーザー定義コンストラクターを完全にサポートするようになったのは9.2まででした。これらの機能がなければ、適切なオブジェクト指向プログラミングは不可能です。
SUPER()を取得できませんでした バージョン11gまで。今でも不足している機能があります。特に、TYPEBODYのプライベート宣言です。 - 構文はしばしば不格好であるか、イライラするほどあいまいです。ドキュメントは役に立ちません。
- Oracleを使用するほとんどの人は、リレーショナル/手続き型プログラミング学校から来る傾向があります。これは、彼らがOOPを理解しない傾向があること、またはOOPがデータベースプログラミングのどこで役立つかを理解できないことを意味します。人々がきちんとしたアイデアを思いついたとしても、Oracleの構文を使用して実装するのは難しいか不可能だと感じます。
その最後のポイントが重要です。新しい構文を学び、Oracleに機能セットを完成させることができますが、Typesの使用法を考え出すことができる場合にのみ価値があります。つまり、継承とポリモーフィズムを使用して解決できる問題が必要です。
私はタイプを多用する1つのシステムに取り組んできました。これはデータウェアハウスシステムであり、データ読み込みサブシステムはタイプから構築されました。根本的な理論的根拠は単純でした：
- ロードするすべてのテーブルに同じビジネスルールテンプレートを適用する必要があるため、プロセスは一般的です。
- すべてのテーブルには独自のプロジェクションがあるため、SQLステートメントはそれぞれに固有です。
Typeの実装はクリーンです。汎用プロセスはTypeで定義されています。各テーブルの実装は、そのジェネリック型から継承する型で定義されます。特定のタイプはメタデータから生成できます。このトピックについては、数年前にUKOUGで発表しましたが、ブログに詳しく書いています。詳細をご覧ください。
ちなみに、リレーショナル理論には、制約などを含むユーザー定義のデータ型であるドメインの概念が含まれています。RDBMSのフレーバーは実際にはドメインをサポートしていませんが、Oracleの型実装は間違いなくその道のりです。