我相信我们正在转向 Oracle Apex 以实现未来的发展。我在 wikipedia 上阅读了有关 Oracle Apex 的信息，它的优点和缺点。在我看来，弊大于利，但也许我错了。我的感觉是 Oracle Apex 是为几乎没有编程知识的 DBA 设置的，可以像 MS Access 一样快速设置 Web 应用程序。
如果您有 Oracle Apex 的工作经验，可以分享一下您的想法吗？从 Wikipedia 的条目来看，您似乎不需要了解任何编程语言，只需要了解 PL/SQL？
编辑：Oracle Apex 是否可扩展？它可以像 Facebook 那样处理流量吗？
编辑：在 Oracle Apex 3.2 上工作了近两年。我可以肯定地说我讨厌它，我不明白为什么有人想在浏览器、pl/sql 上创建 web 应用程序/页面，而没有办法进行版本控制。
感谢。
杰克
请注意我的经验是使用 APEX 2.x-3.0。
在 12 个月的时间里，我将 Apex 用于一些内部应用程序，但最终将其用于 ASP.NET。
一些 Oracle 传道者声称它能够创建与 ASP.NET/J2EE 等更主流框架相当的高度动态内容。从技术上讲，这是真的，但从技术上讲，你可以乘坐单人独木舟穿越大西洋也是如此。如果您想将自己投入到一个复杂程度适中的 APEX 项目中，那么我建议您查看一个简单讨论论坛的 APEX 示例。将其与 ASP.NET MVC 讨论论坛示例或 RoR 实现进行比较。
话说回来：
好的
非常容易生成一个具有基本 CRUD 数据输入、简单报告并用数据填充它的受人尊敬的 Web 应用程序。如果您是负责将公司的 Excel/Access 数据库整合到中央数据库/Web 环境中的 IT 人员，那么您应该看看 APEX，它非常适合这项任务。如果您期望范围增长到甚至中等复杂性，那么我将直接转向更灵活的框架。
如果您是 DBA/PLSQL 专家，但没有传统 Web 开发经验，那么您将做好充分准备，在 Web 应用程序中公开现有业务逻辑，而无需使用 HTML/CSS/JavaScript。
APEX 支持论坛拥有大量信息，并且配备了 APEX 开发人员。
坏的
当应用程序超越 CRUD 数据输入并需要更多动态和事件驱动的行为时，我对 Apex 的体验开始走下坡路。
基于 Web 的 GUI 并不酷。调试很痛苦。
版本控制？谁需要版本控制？
当您（不可避免地）需要在框架的有限范围之外做任何事情时，您将不得不亲自动手使用 PL/SQL。针对数据库编写业务逻辑很好，但在 2007 年，从 PL/SQL 过程生成 HTML 让人感到不舒服。
鉴于您可以隐藏页面和重定向逻辑的大量偷偷摸摸的地方，程序流程既难以可视化，也不利于模块化、可分离和可重用的代码。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 的数据输入和报告，那么值得一看。如果您正在为动态 Web 内容和丰富的 UI 交互寻找 .NET/JAVA/PHP 的替代方案，我建议您到别处寻找。
我怀着极大的兴趣阅读了这一页。我们的开发团队已经使用 Apex 大约 2 年了，我想总结一下我们的经验。
对于构建基本的 CRUD 应用程序，Apex 确实非常出色。事实上，我建议您自己尝试一下。我们确实在设置它时遇到了一些最初的小困难，但这些似乎已经在 3.2 版本中解决了。
好的
坏的
调试器很糟糕。如果您使用过 Visual Studio（甚至是旧版本的 Microsoft Access），您会对调试器感到畏缩。没有断点，调试消息在大列表中喷出到屏幕上，不得不手动将调试消息打印到屏幕上。可怕。许多、许多小时失去支持的事业。
一旦您的应用程序变得复杂或需要任何丰富的功能，您就必须求助于 Javascript 和 HTML / CSS hack，这会使调试和支持变得更加复杂（尽管您可以使用 Firebug 或 Visual Studio 等工具来协助解决此问题）。
我们遇到了无法解释的会话状态错误，样式表在没有解释的情况下从应用程序中“分离”——仅举几个问题。
支持不熟悉的应用程序可能具有挑战性，因为如果没有好的调试器，可能很难遵循页面逻辑流程。而且我不买“好吧 - 应用程序应该编码得更好”的股票反应。因为在现实世界中，它们不是——尤其是当您使用承包商时。
报告看起来不错，但如果您无法打印或导出为 PDF，则效果不佳。当然你可以买一个报告服务器，最后我们使用了另一种解决方案。
全面的
我会说一定要将 Apex 用于简单的 CRUD 应用程序。对于任何复杂程度不高的东西，请使用 .Net 或 Java。我不会注意到 Apex 上的 Wiki 文章，因为它非常歪曲。请注意“难以调试”（我认为最大的失败）已从文章中删除。
还需要非常警惕的是，您可以快速将 Access 数据库直接转换为 Apex 的荒谬说法。是的，如果您的 Access DB 非常非常简单，它将起作用。正如我们发现的那样，任何中等复杂的东西，算了吧。
我们绝对不会将它用于面向 Web 的应用程序，仅用于内部应用程序。做你认为理所当然的事情，比如.Net，有太多的困难。我知道有一些网站，例如 AskTom，但这些网站并不十分复杂。我们会在上面看到下一个 Facebook 吗？我认为不会——尽管我确信读到这篇文章的人会对此有所了解。
Apex 在之前的评论中得到了总结——经理们看到了演示，很快就接受了，确信他们找到了可以缩短开发时间的灵丹妙药。我有经理打电话给我说，我们需要一个 db 应用程序，请在一周内在 Apex 中构建 40 个表 - 这就是神话已经发生的程度。实际情况有些不同。是的，有些事情更快、更快，但您会在其他领域浪费时间——调试、支持和定制。
当然你最好自己决定。安装它，试一试，你可能会喜欢它。但是，在您对实际应用程序进行了很好的审查之前，不要被快速开发时间的说法所迷惑。
我参与了一个将 5000 个模块的 Oracle Forms 应用程序迁移到 APEX的大型项目。这是对 APEX 的极端使用，但它工作得很好。APEX仅适用于由 DBA、实习生或最终用户构建的小型内部应用程序完全是一个神话：它当然也适用于那些（并且比大多数其他工具更适用），但它也可以用于构建极其复杂的应用程序。
要构建复杂的应用程序（而不是默认的开箱即用的 APEX 应用程序），您需要团队中具有 Javascript 技能和 CSS 技能的人。但大多数开发人员最初只需要 PL/SQL。
是否可扩展？是的：可能比大多数其他解决方案更具可扩展性！APEX 对数据库服务器的开销非常小，并且只需要最少量的应用程序服务器。“脸书大小”？我不确定，但我不明白为什么不这样做，假设您在一台足够大且功能强大的机器上有一个 Oracle 数据库，可以处理“Facebook 大小”的数据和交易量。与任何 Oracle 项目一样，可扩展性主要受到不良数据库设计和编写不佳的 SQL 的阻碍，而不是工具。不过，没有多少人会发现自己正在构建“Facebook 大小”的系统：你是吗？
APEX 是一个使用数据库和 PL/SQL 来生成网页的框架。如果您能弄清楚浏览器的输出需要是什么，您可以在 APEX 中创建它。如果您发现框架的任何部分存在限制，您可以编写 PL/SQL 过程并将它们直接公开给 Web 服务器，但仍然可以利用 APEX 系统为您管理的安全性、日志记录、会话状态等。
您应该了解 PL/SQL、SQL、HTML、JavaScript 和 CSS。当然，界面看起来像一个大数据输入应用程序，但您输入的数据主要是每种语言的代码片段。
它的扩展性和数据库一样好。它通常使用 Apache 作为 Web 服务器，但仅用于提供静态文件并将请求传回数据库，其中网页由 APEX 模式中的 PL/SQL 代码创建。您可以使用 AJAX 来最小化上下管道的流量大小。您可以为特定项目、列表、页面区域、页面等设置缓存。
由于框架中的大多数事情都非常简单，自然会有一些事情在框架内做起来稍微复杂一些。上面给出的颜色编码示例可能是您使用 CSS 执行的操作，或者您可能需要使用打印语句来生成所需的输出。问题是学习框架如何让生活更轻松，然后当你达到极限时，你可以轻松地求助于更直接的方法。
来自 VB.Net 你会错过一步一步的调试和拖放。您永远不会错过这样一个事实，即页面生命周期的某些部分将执行绑定并重置您绑定到页面另一部分中的对象的值。
祝你好运。
格雷格
我是一名 DBA，我从来不需要使用 APEX 或最近使用其他任何东西进行编程（除了一些用于管理目的的 bash 脚本和自定义 SQL 脚本），因为我的工作远离开发应用程序（除了让开发人员感到痛苦之外） . 当然，我的背景是开发人员，我相信 APEX 是严格基于 Oracle 的以数据为中心的程序的未来。
现在这里的关键词是以数据为中心，因为我不同意许多其他 DBA 的观点，即所有应用程序都是以数据为中心的（你知道那种仍然认为 ODBC 代表ORACLE数据库连接的 DBA）。当然，所有应用程序都涉及数据，但所有应用程序都以数据为中心吗？我怀疑，就像我怀疑 APEX 是否会用于图像处理或移动游戏类应用程序一样。然而，尽管 RIA 和 Web 2.0 大肆宣传，但事实是我们周围的大多数企业都渴望那些以数据为中心的普通旧应用程序，而 Oracle 是最好的数据库，我可以向您保证，Oracle 和 APEX 可以处理的不仅仅是 Facebook 的可扩展性当然，前提是你在底层基础设施上投入了与 Facebook 人员相同数量的资金。
顺便说一句，我也讨厌 Oracle 的 APEX 主题设计（糟糕的不专业的 UI，想象一下它是银行或航空公司业务的主要 UI）、有限的功能（尽管这似乎在未来会改变）、更多的问题（专业PDF 报告无需为 BI 发布者支付企业数据库许可？触摸我的数据库:)
你看，Oracle 有一个叫做 PL/SQL 的 gem，它多年来一直在完善，以比任何其他语言更直观的方式处理数据。现在，随着 Forms/Reports 的缓慢死亡，宝石正在枯萎，我很肯定，没有一个应届毕业生会费心去严格地学习它以用于数据库存储过程（只要看看 Java 和 .Net 开发人员之间的激烈战争，你就会意识到，一旦你接触了大括号{} 其他任何东西都会成为异端）。对于成千上万的优秀 PL/SQL 开发人员来说，APEX 仍然是他们可以保持生产力并开发出色的以数据为中心的应用程序的唯一避难所，没有 APEX PL/SQL 肯定会成为下一个 COBOL。这就是为什么 PL/SQL 社区将推动 Oracle 将 APEX 转变为比我们今天看到的更强大的 A 级平台。
我不确定你为什么不认为 PL/SQL 是一种编程语言......
APEX 非常适合您希望在数据之上拥有轻量级 UI 的内部应用程序。您可以相当轻松地构建它，而无需编写任何代码。
我还发现 APEX 非常适合开发较小的面向客户的应用程序。我不想构建一个巨大的应用程序，它会让数百名开发人员使用 APEX 来开发它。但是，如果您有 3 或 4 名开发人员正在构建一个小型站点的情况，那么 APEX 很可能与 Java/PHP/ASP.Net/假设同样熟练的开发人员一样好。例如，如果您的开发人员都拥有大量 ASP.Net 专业知识，那么他们将有一个学习曲线来编写 APEX 应用程序。但是，如果您有一群 PL/SQL 开发人员尝试学习如何构建 ASP.Net 站点，那么您至少会遇到同样的难度。
不要将业务逻辑放入 Apex。仅用于演示。
如果您将代码放在应用程序中，您将无法维护它，并且您将通过所有点击获得 RSI。我总是创建一个包装层，并且在 Oracle 世界中遵循 Tom Kytes 的建议 - 将业务逻辑尽可能靠近数据。这也意味着您的 PL/SQL 模块可以被其他系统等调用 - 最重要的是 - 您的应用程序的真正核心将是可以使用您最喜欢的文本编辑器/IDE 操作的纯文本文件。
简而言之：
不要将您的应用程序逻辑放在 APEX 中。
那是我的建议。. . .
Apex 仅适用于非程序员和 DBA 是一种不幸的误解。我们已经使用它来构建多个业务线、任务关键型、面向客户的 Web 应用程序。
GUI 由 Apex 页面模板 (HTML)、CSS 和一些 Javascript 处理，以增强用户体验。所有业务逻辑都放在 PL/SQL 包中。这是使您的应用程序易于维护以及在其他 Apex 应用程序和其他客户端工具（例如 C# WinForms、Delphi、Java 应用程序等）中重用业务逻辑的关键。
至于性能，Apex 引擎增加的开销很小，应用程序的响应时间和可扩展性很大程度上取决于 SQL 查询（和数据模型）的质量。可以这样想：使用 Apex，您的用户和数据库之间唯一的东西就是一层薄薄的 PL/SQL。这是常识，它必须比在 GUI 和数据库之间具有 17 层复杂性（通常包括大量 Web 服务和对象关系映射层）的典型 .NET 或 Java 应用程序更快。
Oracle 的 Metalink 支持站点是用 Apex 编写的，因此它绝对可以扩展。不过，他们现在正在迁移到一个更新的基于 Flash 的支持站点。我知道他们通过收购另一家公司获得了该平台，而不是为了响应任何 Apex 限制而构建它。
如果你想用任何网络应用程序“超级性感”，你可能需要使用 Flash/Silverlight/Air。在此之下，任何基于 HTML 的站点，包括 Apex 站点，都可以使用 Javascript 进行美化。JQuery 库将包含在 Apex (4.0) 的下一个主要版本中，尽管您现在可以包含该版本（或任何其他库）。
Wikipedia 文章中提到的缓存问题已得到解决，尽管大多数安装仍会将图像和脚本放在传统的目录结构上，而不是从数据库中提供它们。
当您被锁定在 Oracle 数据库中时，我没有得到文章中的“平台”锁定“con”。Oracle 可用于 Windows、Linux 和 AIX（以及其他）。这比 ASP / SQL Server 少了很多锁。
在我的项目中，我们使用 Oracle APEX 来查看系统的内部视图。它非常适合这个目的。
无需编程。 PL/SQL甚至SQL是可选的。因此，我们的 DBA 和操作员可以根据自己的喜好塑造视图。
不利的一面是，如果您需要的功能未编程到系统中，则很难添加它。例如，我们想对我们的输出进行颜色编码，但无法做到这一点。
我不想在 APEX 上构建面向客户的网站。
关于可扩展性的问题，APEX 的一个优点是它建立在 Oracle 之上。专注于编写好的 SQL 和正确设计表，事情应该可以很好地扩展。我会更关心获得足够多的用户来解决可扩展性问题。
非常喜欢从上到下阅读该主题，因为这感觉像是一场激烈的辩论。为了提醒线程的开头，它以“我相信我们正在迁移到 Oracle Apex 以进行未来开发......”作为 .NET 程序员的杰克担心他的管理层的决定并考虑为 Oracle Apex 寻找相反的事实最终最终在公共场合清洗了（所有 Web 框架的）肮脏的亚麻布。尽管受害者是 Oracle Apex，但如果在 .net 和 j2ee 专家之间进行辩论，同样的情况也可能发生在 .net 或 j2ee 上。我的观点是所有框架都有自己的优点和缺点。这就是为什么我们实际上有这么多。争论什么对生活更重要（性、食物或水？）当然，我们会在需要时选择最合适的项目，这是浪费时间。
如果您想查看在 APEX 中完成的外部网站，我建议您查看Oracle 工具用户组网站或询问 Tom。两者都是大型、经常使用的网站，具有很多自定义功能。
您对维基百科文章的印象是正确的。您需要的唯一编程知识是 PL/SQL。如果您的大部分站点都是简单的报告，您甚至不需要编写 SQL 查询，向导界面将为您构建查询和输出。如果你想要很酷的客户端工作，你需要了解 CSS 和 Javascript。PL/SQL 仅用于更复杂的数据验证。
我不同意。它不仅适合具有少量开发技能的开发人员或 DBA。
实际上，我们使用我们自己的 CSS 模板、大量动态操作和交互（使用 jQuery 和几个框架）、微调的安全性、我们自己的 apex 插件和复杂的 PL/SQL 流程来生产高度定制的应用程序。
当然，我使用的是 apex > 4.0。
因此，如果需要，您可以构建复杂的应用程序（我们每个页面有多达 100 个不同的流程/验证和动态操作）。并且它可能需要强大的编程技能才能在 javascript 和 PL/SQL(OOP) 或 Java 存储过程中正确编码 + 良好的 SQL 知识以使用递归 SQL 和一些有趣的功能定义多达 500 行代码的优化查询。