目次

目次
About Oracle Apex
時代は脱Oracle
保守性が低い
データベースとアプリケーションが密結合である
モダンな開発と相性が悪い
不明な注意点
Oracle Apexを採用しても良い場合
終わりに

About Oracle Apex

Oracle Apexとは、Oracle Databaseに密結合で、データベースファーストなWebアプリケーション用ローコード開発プラットフォームです。

Oracle Database上のテーブルや、REST API、CSV等から、それらのデータを利用するWebアプリケーションを簡単に作成することができます。

ローコードツールであるため、GUIを利用して作成しますが、GUIでは足りない機能を実装する場合、フロントサイドとしてはJavaScriptを、サーバーサイドとしてはPL/SQLを利用してアプリケーションを作成します。

データベースと密結合であり、サーバーサイドはPL/SQLを利用するため、高速です。

時代は脱Oracle

今は、脱Oracleの時代です。

Oracleの高額で複雑なライセンス料金、貧弱なSQLパーサー、ナンセンスなマルチテナントアーキテクチャ、使いづらいツール類、ベンダーロックイン...などなど、Oracleを利用するのは、最早時代遅れです。

今や、より高性能で、高機能、低コストのOSSがあります。

にも関わらず、Oracle ApexはOracle Databaseをバックエンドとして要求します。

他のデータベースでもバックエンドとして使えるのならば、問題にはなりませんが、実際にはデータソースとしてMySQLを利用することができるのみです。

これらの仕様は時代に逆行しているとしか言えません。

保守性が低い

コードで実装する場合、サーバーサイドはPL/SQLを利用して記述されます。

PL/SQLは、データクエリ等を行う問い合わせ言語であるSQLを拡張し、プログラミング言語にしたものです。

ですが、PL/SQLは可読性が低く、メンテナンスや機能追加が、実装した本人でなければ(あるいは実装した本人ですら)、難しいです。

PL/SQLは、DBAの人がデータベースの管理をするためのツールとして利用する分にはいいですが、それ以外の場合は、利用するべきではありません。

また、データベースにロジックが含まれると、スケーリングにおいて問題が発生します。

データベースにロジックを含めるべきではありません。

また、Oracle Apexだけでなく、ローコードツール全般に言えることですが、GUIで実装する場合においても、行った変更に合わせて、最適になるようにパラメータが変更されますが、このパラメータ調整によって意図しない部分まで変更されてしまい、どの部分が変更されたかわからなくなってしまう問題が発生します。

また、GUIでの実装では同じような機能を複数の場所で定義できるので、どこを見ればよいかわかり辛く、更にコードでの実装と組み合わせてカオスになります。

データベースとアプリケーションが密結合である

3層Webアプリケーションとしては、データーベースサーバー、アプリケーションサーバー、Webサーバーと分離されています。

分離されているのには理由があります。

これらが、分離されていない場合、各レイヤーで発生した問題への影響範囲が他のレイヤーまで、広がってしまいます。

また、データベースとアプリケーションが密結合な場合、スケーリングに問題が発生します。

モダンな開発と相性が悪い

Gitを利用してソースコードを管理、CI/CDを回して、自動テスト・自動デプロイのようなことができません。

Oracle Apexの場合、GUIで作成された部分も実際にはPL/SQLが生成されているため、PL/SQLをエクスポートして、Gitで管理することもできますが、いちいちエクスポートする必要があります。

不明な注意点

可用性は?

Oracle RACのようなクラスタ構成にした場合、Oracle Apexもクラスタによる高可用構成になっているのか?

Oracle Apexを採用しても良い場合

これは、以下の3点に絞られます。

Oracle Databaseを使っているDBAがDBAのための管理ツールとしてのWebアプリケーションを作成する場合
Oracle Databaseを利用しており、機能的にGUIで設定できる項目のみ利用する(JavaScriptやPL/SQLを手動で作成しない)場合
Oracle Databaseを利用して、REST APIを作成する場合

DBAの管理ツールとして利用する場合は、データベースとよく統合されているため、扱いやすく、スケーリングも問題になりません。

機能も、そこまでこだわって実装する必要がないので、基本的にGUIで利用できる機能とそれほど複雑ではないPL/SQLで実装可能であるため、デメリットよりもメリットの方が大きいと考えられます。

同じく、機能の要件にそれほど厳しくないものである場合、デメリットよりもメリットの方が大きい可能性があります(現実問題としてDBAの範囲から抜け出してしまうとそうならない場合の方が大きいと思いますが)。

また、REST APIを作成する機能のみを利用する場合も、デメリットの少ないユースケースと言えそうです。

~~脱Oracleどころかより依存していってる点を除けば...~~

終わりに

Oracle Apexは、自分でコーディングする技術を持たないDBA用の玩具です。

そんなもので、実際に業務で利用するアプリケーションを作成するというようなことは考えない方がよいです。