将来の開発のために Oracle Apex に移行していると思います。ウィキペディアで Oracle Apex について読んだことがありますが、賛否両論です。短所が長所を上回っているように思えますが、間違っているかもしれません。Oracle Apexは、プログラミングの知識がほとんどまたはまったくないDBA向けであり、プログラマーがいない場合のMS AccessのようにWebアプリケーションをすばやくセットアップするためのものであると私は感じています。
Oracle Apexでの実務経験がある場合は、考えを共有できますか? ウィキペディアのエントリから、プログラミング言語をまったく知る必要がないように見えますが、PL/SQL だけですか?
編集: Oracle Apex はスケーラブルですか? Facebook のようなトラフィックを処理できますか?
編集：Oracle Apex 3.2で2年近く働いた後。私はそれが嫌いだと安全に言うことができ、ブラウザ、pl/sqlでWebアプリケーション/ページを作成したいのに、バージョン管理を行う方法がない理由がわかりません。
感謝。
ジャック
私の経験は APEX 2.x-3.0 であることに注意してください。
12 か月間、いくつかの内部アプリに Apex を使用しましたが、最終的に ASP.NET 用にダンプしました。
一部の Oracle エバンジェリストは、ASP.NET/J2EE などのより主流のフレームワークと同等の高度に動的なコンテンツを作成できると主張しています。技術的にはこれは真実ですが、1 人乗りのカヌーで大西洋を横断できることも技術的には真実です。中程度の複雑さの APEX プロジェクトに身を投じたいという誘惑に駆られた場合は、単純なディスカッション フォーラムの APEX サンプルを参照することをお勧めします。ASP.NET MVC ディスカッション フォーラムのサンプルまたは RoR 実装と比較してください。
そうは言っても：
いいもの
基本的な CRUD データ入力、シンプルなレポート作成、データの入力を備えた立派な Web アプリを驚くほど簡単に生成できます。会社の混乱した Excel/Access データベースを中央の DB/Web 環境に統合する任務を負っている IT 担当者であれば、APEX を検討する必要があります。APEX はこのタスクに非常に適しています。範囲が中程度の複雑さまで拡大すると予想される場合は、より柔軟なフレームワークに直行します。
DBA/PLSQL の第一人者であるが、従来の Web 開発の経験がない場合でも、必要がなければ、HTML/CSS/JavaScript を詰め込むことなく、既存のビジネス ロジックを Web アプリに公開する準備が整っています。
APEX サポート フォーラムには大量の情報があり、APEX 開発者が配置されています。
悪い人
アプリが CRUD データ入力を超えて、より動的でイベント駆動型の動作を必要とするようになったとき、Apex での私の経験は下り坂になり始めました。
Web ベースの GUI はクールではありません。デバッグは苦痛です。
バージョン管理？バージョン管理が必要な人
(必然的に) フレームワークの制限された範囲外で何かを行う必要がある場合は、PL/SQL を操作する必要があります。データベースに対してビジネス ロジックを記述することは問題ありませんが、PL/SQL プロシージャから HTML を生成することは、2007 年には不快なほど古風に感じられました。
ページとリダイレクト ロジックを非表示にできる巧妙な場所が多数あることを考えると、プログラム フローは視覚化が困難であり、モジュール化された分離可能で再利用可能なコードを自然に助長するものではありません。OOP 開発者は感銘を受けません。APEX を使用して適切に構造化された保守可能なアプリケーションを作成することは可能ですが、それは必要以上に困難です。これは MVC とはかけ離れた世界です。
私が使用したバージョンの許容できない数のフレームワークのバグ。これが最近のバージョンで改善されていることを願っていますが、IDE を APEX プラットフォーム自体に統合するというパラダイムにより、私の人生で最も暗く、魂を破壊するデバッグ セッションが発生しました。例として、ユーザーがセッション データを失う原因となる断続的なバグを再現しようとしました。セッション情報ポップアップを使用すると、セッション データが変更されるべきではないときに変更されることがあることがわかりました。コード内のエラーを見つけるのに 2 日間を費やしましたが、うまくいきませんでした。ほとんど錯乱状態で、デバッグ ウィンドウでエラーのあるセッション データを再現できたのに、アプリケーション自体はエラー状態にならないことに偶然気付きました。. 何が起こっているのかを理解したとき、私の心は沈みました。Oracle は後で、セッション情報ウィンドウに以前のセッションのデータが断続的に表示される APEX のバグを発見したことを確認しました。バグのあるセッション デバッグ ウィンドウを使用して、セッション関連のバグをデバッグするのに 2 日間を無駄にしました。それが私が作成した最後の Apex アプリでした。
PL/SQL は、Web 開発における次のビッグ シングではありません。しばらく APEX で働いた後、私はそれが私をより良い Web 開発者にするつもりはないことに気付きました。APEX をマスターすることは、実際には PL/SQL に関するものです。キャリアを Oracle テクノロジーに集中させることを計画している場合は問題ありませんが、APEX は主流の Web テクノロジーの方向性と非常に接しているため、APEX から他の Web フレームワークに引き継ぐことができる一連の移植可能なスキルは最小限であることに注意してください。
APEX でシンプルな Web ベースのデータ入力とレポート作成を検討している場合は、一見の価値があります。.NET/JAVA/PHP に代わる動的な Web コンテンツと豊富な UI インタラクションを探している場合は、他の場所を探すことをお勧めします。
私はこのページを非常に興味深く読んだ。私たちの開発チームは約2年間Apexを使用していますが、私たちの経験を要約したいと思います。
基本的なCRUDアプリケーションを構築するために、Apexは本当に優れています。実際、自分で試してみることをお勧めします。最初の小さな問題に直面しましたが、3.2リリースで解決されたようです。
いいもの
悪い人
デバッガーはひどいです。Visual Studio（および古いバージョンのMicrosoft Access）を使用したことがある場合は、デバッガーに夢中になるでしょう。ブレークポイントはありません。デバッグメッセージが大きなリストの画面に表示され、デバッグメッセージを手動で画面に出力する必要があります。最悪。サポートに何時間も失われた原因。
アプリケーションが複雑になるか、豊富な機能が必要になるとすぐに、JavascriptとHTML / CSSハックに頼る必要があります。これにより、デバッグとサポートがさらに複雑になります（ただし、FirebugやVisual Studioなどのツールを使用してこれを支援できます）。
原因不明のセッション状態のバグが発生し、スタイルシートが説明なしにアプリケーションから「切り離される」ようになりました。たとえば、いくつかの問題があります。
使い慣れていないアプリのサポートは、優れたデバッガーがないとページロジックフローをたどることが難しい場合があるため、難しい場合があります。そして、私は「まあ、アプリはもっとうまくコーディングされるべきだ」という株の反応を買わない。なぜなら、現実の世界ではそうではないからです。特に請負業者を使用している場合はそうです。
レポートは見栄えがしますが、印刷したりPDFにエクスポートしたりできない場合はあまり良くありません。もちろん、レポートサーバーをシェルアウトすることもできますが、最終的には別のソリューションを使用しました。
全体
単純なCRUDアプリには必ずApexを使用してください。軽度以上の複雑さについては、.NetまたはJavaを選択してください。Apexに関するWikiの記事は非常に歪んでいるため、私は気づきません。「デバッグが難しい」（私の意見では最大の失敗）が記事からどのように消去されているかに注意してください。
同様に非常に警戒すべきことは、AccessデータベースをApexに直接変換できるというばかげた主張です。はい、Access DBが非常に単純な場合は、機能します。私たちが見つけたように、適度に複雑なものはすべて忘れてください。
Web向けのアプリには絶対に使用せず、内部にのみ使用します。.Netのように、当たり前のことをするのは非常に困難です。AskTomのようなサイトがあることは知っていますが、これらは必ずしも複雑ではありません。次のFacebookが表示されますか？私はそうではないと思います-これを読んでいる誰かがそれにひびを入れると確信していますが。
Apexは以前のコメントに要約されています。マネージャーはデモを見て、すぐに賛同し、開発時間を短縮する特効薬を見つけたと確信しました。マネージャーから電話があり、Apexで1週間に40個のテーブルを作成するdbアプリが必要だと言われました。これは、神話がどこまで進んだかということです。現実は多少異なります。はい、いくつかのことはより速く、実質的に速くなりますが、デバッグ、サポート、およびカスタマイズなどの他の領域で時間を失うことになります。
もちろん、あなたは自分で決めるのが最善です。それをインストールして、試してみてください、あなたはそれを好きかもしれません。しかし、現実的なアプリケーションをうまくやり遂げるまでは、開発時間の短さの主張に惑わされないでください。
私は、5000 モジュールの Oracle Forms アプリケーションを APEX に移行するという巨大なプロジェクトに携わっています。これは APEX の極端な使い方ですが、問題なく動作しています。APEX は、DBA、インターン、またはエンド ユーザーによって構築された小さな内部アプリにのみ適しているというのは完全な神話です。APEXは確かにそれらにも適しています (そして、他のほとんどのツールよりも適しています)。しかし、非常に高度なアプリの構築にも使用できますアプリケーション。
洗練されたアプリケーション (デフォルトですぐに使える APEX アプリケーションではなく) を構築するには、Javascript のスキルと CSS のスキルを持つチームのメンバーが必要です。しかし、ほとんどの開発者は最初に PL/SQL だけを必要とします。
スケーラブルですか？はい: おそらく他のほとんどのソリューションよりもスケーラブルです! APEX はデータベース サーバーにほとんどオーバーヘッドを追加せず、最小限のアプリケーション サーバーしか必要としません。「フェイスブックサイズ」？確かなことはわかりませんが、「Facebook サイズ」のデータとトランザクション量を処理するのに十分な大きさで強力なマシンに Oracle データベースがあると仮定すると、そうしない理由はわかりません。他のオラクル プロジェクトと同様に、スケーラビリティは主に、ツールではなく、不適切なデータベース設計と適切に記述されていない SQL によって妨げられています。しかし、「Facebook サイズ」のシステムを構築していることに気付く人は多くありません。
私は DBA であり、APEX やその他 (管理目的の bash スクリプトとカスタム SQL スクリプトを除いて) を使用してプログラミングする必要はありませんでした。私の仕事はアプリケーションの開発とはかけ離れているためです (ただし、開発者のお尻の痛みを除いて)。 . もちろん、私のバックグラウンドは開発者ですが、APEX は厳密に Oracle ベースのデータ中心のプログラムの未来であると確信しています。
ここでのキーワードはデータ中心です。なぜなら、すべてのアプリケーションがデータ中心であるという他の多くの DBA とは意見が一致しないからです (ODBC はORACLE Database Connectivity の略だといまだに考えている種類の DBA はご存知でしょう)。もちろん、すべてのアプリケーションはデータを伴いますが、すべてのアプリケーションはデータ中心ですか? APEX が画像処理やモバイル ゲームのようなアプリに使用されることはないと思います。しかし、RIA と Web 2.0 の誇大広告にもかかわらず、私たちの周りのビジネスのほとんどは、単純な古いデータ中心のアプリケーションを切望しており、Oracle は最高のデータベースであり、Oracle と APEX は Facebook のスケーラビリティよりもはるかに多くを処理できることを保証できます。もちろん、基盤となるインフラストラクチャに Facebook の担当者と同じ金額を投入していることが前提です。
ところで、私は Oracle の APEX テーマのデザイン (ひどい非専門的な UI、銀行や航空会社のメイン UI と想像してみてください)、制限された機能 (将来的には変更されるようですが)、さらに多くの問題 (専門家のBI パブリッシャーのエンタープライズ データベース ライセンスの金額を支払わずに PDF レポートを作成することはできますか??) しかし、何よりも APEX を Access や Excel の代わりとして宣伝するのは、それが子供向けであるという悪い印象を与えるためです。私のデータベースに触れてください:)
おわかりのように、Oracle には PL/SQL と呼ばれる宝石があり、他のどの言語よりもはるかに直感的な方法でデータを処理するために長年かけて完成されました。現在、その宝石はフォーム/レポートのゆっくりとした死とともに衰退しており、新卒者がデータベースストアドプロシージャについて厳密に学習することを気にすることはないと確信しています（Javaと.Net開発者の間の激しい戦争を見てください。中括弧に触れると、 {} それ以外はすべて異端になります）。残念なことに、何千人もの優れた PL/SQL 開発者にとって、APEX は生産性を維持し、優れたデータ中心のアプリケーションを開発できる唯一の聖域であり続けています。APEX がなければ、PL/SQL は確実に次の COBOL になるでしょう。これが、PL/SQL コミュニティがオラクルを駆り立てて、APEX を今日よりもはるかに強力なグレード A プラットフォームに変換する理由です。
PL/SQLをプログラミング言語と見なさない理由がわかりません...
APEX は、データの上に軽量の UI が必要な内部アプリケーションに最適です。コードを書かなくても簡単にビルドできます。
また、小規模な顧客向けアプリケーションの開発には APEX が非常に適していることもわかりました。何百人もの開発者が APEX を使用して作業する巨大なアプリケーションを構築したくありません。しかし、3 人か 4 人の開発者が小規模なサイトを構築している場合、APEX は Java/PHP/ASP.Net など、同等のスキルを持つ開発者を想定したものと同じくらい優れている可能性があります。たとえば、開発者全員が多くの ASP.Net の専門知識を持っている場合、APEX アプリを作成するための学習曲線が必要になります。ただし、多くの PL/SQL 開発者に ASP.Net サイトの構築方法を学ばせた場合、少なくとも同じレベルの難易度になるでしょう。
ビジネスロジックを Apex に組み込まないでください。プレゼンテーションのみに使用してください。
コードをアプリに入れると、それを維持できなくなり、そのすべてのクリックから RSI が得られます。私は常にラッパー レイヤーを作成します。オラクルの世界では、Tom Kytes のアドバイスに従います。ビジネス ロジックをできるだけデータに近づけます。これは、PL/SQL モジュールを他のシステムなどから呼び出すことができることも意味します。何よりも、アプリケーションの真の部分は、お気に入りのテキスト エディター/IDE で操作できるストレート テキスト ファイルになります。
要するに：
アプリのロジックを APEX に配置しないでください。
それは私のアドバイスです。. . .
Oracle の Metalink サポート サイトは Apex で作成されているため、確実に拡張できます。ただし、現在は新しい Flash ベースのサポート サイトに移行しています。Apex の制限に応じてプラットフォームを構築するのではなく、別の会社の買収を通じてそのプラットフォームを取得したことを理解しています。
Web アプリで「超セクシー」が必要な場合は、おそらく Flash/Silverlight/Air に移行する必要があります。その下では、Apex を含む HTML ベースのサイトを Javascript できれいにすることができます。JQuery ライブラリは、Apex の次のメイン バージョン (4.0) に含まれますが、それ (または他のライブラリ) を今すぐ含めることができます。
ウィキペディアの記事で言及されているキャッシングの問題は解決されましたが、ほとんどのインストールでは、画像とスクリプトをデータベースから提供するのではなく、従来のディレクトリ構造に配置していました。
Oracle データベースにロックされている間、この記事では「プラットフォーム」ロックの「con」を取得しません。Oracle は、Windows、Linux、および AIX (その他) で利用できます。これは、ASP / SQL Server よりもはるかに少ないロックです。
熱い討論のように感じられたので、スレッドを上から下まで読んでとても楽しかったです。「将来の開発のために Oracle Apex に移行していると思います...」というスレッドの冒頭を思い出してください。最終的には、(すべての Web フレームワークの) 汚れたリネンを公の場で洗い流すことになりました。被害者が Oracle Apex であったにもかかわらず、議論が .net と j2ee グルの間で行われた場合、同じことが .net または j2ee に発生する可能性があります。私のポイントは、すべてのフレームワークにはそれぞれ長所と短所があるということです。それが、実際に私たちが非常に多く持っている理由です。生きるために何が重要か（性、食物、水？）を議論するのは時間の無駄です。
私のプロジェクトでは、システムの内部ビューに Oracle APEX を使用しています。それはその目的のために非常にうまく機能します。
プログラミングは必要ありません。 PL/SQLさらにSQLはオプションです。その結果、DBA とオペレーターは好みに合わせてビューを作成できます。
欠点として、システムにプログラムされていない必要な機能がある場合、それを追加するのは非常に困難です。たとえば、出力を色分けしたかったのですが、それができませんでした。
APEX で顧客向けサイトを構築したくありません。
スケーラビリティの問題に関して言えば、APEX の優れた点の 1 つは、Oracle 上に構築されていることです。優れた SQL を記述し、適切にテーブルを設計することに集中すれば、問題なくスケーリングできるはずです。スケーラビリティが問題になるのに十分なユーザーを獲得することについて、私はもっと心配しています。
APEX で作成された外部の Web サイトを見たい場合は、Oracle Tools Users GroupサイトまたはAsk Tomを参照することをお勧めします。どちらも大規模で頻繁に使用されるサイトで、多くのカスタマイズが行われています。
ウィキペディアの記事からのあなたの印象は正しいです。必要なプログラミング知識は PL/SQL だけです。サイトの大部分が単純なレポートである場合、SQL クエリを記述する必要さえなく、ウィザード インターフェイスがクエリと出力を作成します。クールなクライアント側の作業が必要な場合は、CSS と Javascript を知っている必要があります。PL/SQL は、より複雑なデータ検証専用です。
同意しません。いくつかの開発スキルやDBAを持つ開発者に適しているだけではありません。
実際には、独自のCSSテンプレート、多くの動的アクションとインタラクション（jQueryといくつかのフレームワークを使用）、微調整されたセキュリティ、独自のapexプラグイン、および複雑なPL / SQLプロセスを使用して、高度にカスタマイズされたアプリを作成しています。
もちろん、私はapex>4.0を使用しています。
そのため、必要に応じて複雑なアプリ（ページごとに最大100の異なるプロセス/検証と動的アクションがあります）を構築できます。また、javascriptおよびPL / SQL（OOP）またはJavaストアドプロシージャで適切にコーディングするには、強力なプログラミングスキルと、再帰SQLおよびいくつかの面白い機能を使用して最大500行のコードの最適化されたクエリを定義するSQLに関する十分な知識が必要になる場合があります。