Apex は無料で、Oracle XE データベースも無料です。頂点は急速な開発です。
しかし、あなたが求めていることは、さらに多くのことに依存します。
私が理解していることから、Oracle に関連する高速で使いやすい開発ツールが必要な場合は、Apex が最初の選択肢です。
Oracle データベースはすでに使用されていますか? 使いやすい開発ツール: はい、もちろんです。しかし、何でもそうであるように、それはあなたがそれについての経験を持っているかどうか、仕様と期待が何であるかに依存します...
複雑なソリューションが必要な場合、APEX は適合しません。
ええと... 複雑なソリューションは、別の環境ではそれほど複雑ではないでしょうか? 私たちはどれほど複雑に考えているのでしょうか。私の意見では、apex でかなり進んで、ニーズに合わせて調整することができます。フレームワークをセットアップするためにテンプレートとプラグインを作成する必要があるかもしれませんが、実行可能です。例としては、ExtJS と完全に統合された頂点プロジェクトがあります。Apexもすべての答えではありませんが、それは良いことです. より複雑で複雑な Oracle スタック内にとどまるなら、次は ADF だと思います。個人的には、私はそれには納得していません。また、長所と短所もあります (たとえば、Java の知識が必要です。賛成する人もいれば反対する人もいます...)。
私の場合、この製品をラケボール クラブに推奨すべきかどうかを知る必要があります。大企業ではないので、HTML DB を実装したらできるだけ操作を少なくしたいので、HTML DB が最良の選択だと思います。
このクラブの規模はどのくらいですか? Web サイトはどの程度使用されますか? DBはもうありますか?オラクルですか?誰が DBA の知識 (基本的であっても) を持っていますか? 誰が開発するの?あなたのスペックがスペック通りであれば、ローンチ後に多くの手を加える必要はないはずです。
また、クラブの所有者がアップデートを開発できる誰かを得るために多額の費用を支払うことも望んでいません。
誰がサーバーをホストしますか? 誰がそれを実行しますか?誰が管理しますか?クラウドベースに移行する予定はありますか?
これが小さなプロジェクトである場合、PHPが良い代替手段になる可能性があることをあえて提案したいと思います。これらの開発者は、apex/oracle 開発者よりも見つけやすく、費用もかからない場合があります。ただし、アウトソーシングを計画している場合は、それほど問題にならない可能性があります。オラクルのインスタンスがどこかのクラウドにあれば、かなり安全だと思います...
本当に、どのオプションを比較しようとしていますか? apex について質問していますが、使用経験はありますか?
正直なところ、あなたの質問は質問ではなく、議論の始まりです。各テクノロジーとデータベースには、長所と短所、ファンと嫌いな人がいます。
個人的にはapexが好きです。特にOracleスタックにすでに投資している場合は、多くのことが期待できます。そして、それはまだ成長しており、優れたサポートと、多くの新機能を備えた優れたリリースを得ています.
(信頼できる) サービスを最初からどのようにセットアップする必要があるかについては、実際には言えません。サーバーとデータベースは、どんなに小さくてもかまいません。そのためには、ある程度の理解と知識が必要です。翼を広げて指を交差させると、どこかで火傷します。開発も同じ。しかし、私が懸念している限り、それは他の技術にも当てはまります。もちろん、それらの側面を外部委託しない限り。
などなど。このように議論すべきことはますます多くあります。
私はこれらの理由からそこに反対票を投じました.議論すべきことがたくさんあります.決定的な答えがある質問はそれほど多くありません. そして、より多くの仕様を提示し、並行プラットフォームの人々に応答してもらう場合にのみ、決定的な答えを得ることができるかもしれません.
編集
ダニエルの投稿に反応したいと思います。
まず、私はもともと PHP 開発者であり、この言語と環境がとても気に入っています。それにもかかわらず、私はこの夏にインターンシップを行うことに決め、現在 APEX で働いています。別のインターンと一緒に、より大きなアプリケーションを開発しています。役立つ情報を提供したいと考えています。私はデータベース管理などにはあまり関与していないので、これはアプリケーションの開発のみをカバーしています (ただし、MySQL データベースを備えた PHP Webspace も管理するのは難しくありません。ユーザー数が多すぎない)。
私も開発者で、サーバーとデータベースの管理 (企業環境) は行いません。余暇にあちこちで手を出していないわけではありませんが、脱線します。
しかし、私の経験では、この範囲外のタスクを解決するのは非常に困難です。これは、1 つのレポートで複数のテーブルを取得できないという意味ではありません。テーブルの結合も大きな問題ではなく、簡単に実現できます。しかし、アプリケーションにこれ以上のものが必要な場合、私は APEX をお勧めできません。そのため、複雑なアプリケーションは別の方法で作成する必要があるという規則に完全に同意します。
PHP 開発者として言えば、これを実現するために PHP を勧めますか? それほど複雑ではないでしょうか。
複雑さについても議論します。私はいくつかの大きなフォームに取り組んできました。これは、私にとって、平均以上の項目、いくつかの動的アクション、検証、おそらくいくつかのカスタム プロセスがあることを意味します。私は非常に複雑な状況に遭遇したことはありません。既成概念にとらわれずに考えることは、時には美徳かもしれませんが、それは既成概念が常に悪いという意味ではありません。複雑なメカニズムやページは、より簡単に達成できる部分に分割できる場合があります。例としては、モーダル ページを使用して分割します。
また、プログラミング経験が限られているというスローガンは部分的にしか当てはまらないと思います。すでに述べたように、簡単なアプリケーションしかない場合にのみ当てはまります。個人的には、IDE と「使いやすい」フォームが混在していることにも我慢できません。
プログラミング経験が限られていることに同意します。最も基本的なフォームとレポートしか作成できず、経験がほとんどないため、何かを壊すことを恐れてオプションページでさえ敬遠すると思います。基本的なデータベースとサーバーの管理でも同じことが言えます。経験豊富なバックアップがない場合、そのような人に頼りたくありません(しかし、明らかに説明されているような非常に小さなプロジェクトは受け入れられるかもしれません)。
私もプログラミング面だけに投資しています。
また、新しいテンプレートなどを作成するのも簡単ではありません。少なくとも私の意見では、他のフレームワークを使用するとはるかに簡単になります。
テンプレートは物事を非常に柔軟にし、確かに使いにくいものではないと思います
そして、おそらく最悪のこと: このアプリケーションはかなりバグが多いと思います。プロセス/ページ/検証の単純な削除と新規作成、または問題を解決したものは何回あるかわかりませんが、この解決策を考えていないだけです。
わお。私はこれに強く反対します。私はおそらく、1年の間に1つのそのようなものに遭遇し、大量のフォームに遭遇しました. OTN フォーラムでいくつかの問題を聞いたことがないわけではありませんが、通常はアップグレードに関係していました。
要約: APEX に本当に適合するアプリケーションがある場合にのみ APEX を使用します。つまり、レポートとフォームだけであり、それ以上のものはすべて、苦痛なデバッグ セッション (この環境ではこれも簡単ではないため...) と悪いメンテナンスにつながります。
apex を使用する大規模な公開サイトがそれほど多くないのは残念です。私が知る限り、apex を含む大規模なプロジェクトがあり、実際に行われてきましたが、それらは通常、企業環境にあるため、誇示されることはありません (できません)。私は個人的に、あなたが言及した基本的なフォーム+レポートよりもapexをはるかに推し進めることができると信じています(そして、基本的なことを意味します。これは、通常、このコンテキストではフォーム+レポートに帰着するからです)。
ただし、デバッグは苦痛である必要はありません。独自のコードで十分なデバッグ メッセージとコメントを提供すると、非常に役立ちます。ページのデバッグ、javascript コンソール、および必要に応じて、plsql パッケージで使用される自律的なエラー ログ プロシージャなど... 役立つことはたくさんあると思います (これに駆り立てられている場合は、作業を行っていることになります)。いくつかのより複雑な素材で、設定した複雑さを実際に処理する知識があることを前提としています)。
そして最後に挙げた興味深い点はメンテナンスです。apex が大幅に改善すべきポイントは、すぐに使用できるバージョニングだと思います。エクスポートを改善して、より簡単に分割できるようにする必要があります。
うわー、そのテキストの壁を見てください.これが議論になると推測できました.