在顶点中添加日期检查约束

时间:2014-05-25 14:14:09

标签: sql database oracle constraints oracle-apex

我有一个表格,其中包含“开始日期”字段和“结束日期”字段。 如何为Oracle Apex编写约束,以使结束日期始终大于开始日期?

我可以在约束中写下这样的东西:enddate> startdate?

2 个答案:

答案 0 :(得分:2)

在Oracle Apex中使用内置表单验证逻辑

我同意上述@Justin Cave的答复。如果数据具有所需的关系,例如begin_date< end_date,这应该在源头强制执行。

表级检查约束

表约束是一种执行此操作的方法。我将借用第一条建议,这将防止您的数据集出现任何不合逻辑的损坏:

 ALTER TABLE bravo_unit_timetable
   ADD CONSTRAINT bravo_unit_timetable_ck
       CHECK( end_period_date > begin_period_date  or
              end_period_date is null );

ANY 如果不遵循此约束,则会过滤并阻止在此情况下应用于表格的DML。


检查约束和APEX错误处理的真实示例

应用表级检查约束是一个部分解决方案,因为问题被标记为。该表是Apex环境的一部分,该环境还包括应用程序级元素。

在Apex中构建表单以处理此表中的数据输入后,Apex表单中的解释DML不是非常友好:

Oracle Apex Data Entry Without Date Range Validation

屏幕截图的顶部显示输入表单中日期值的无效日期配对结果:

  • begin_period_date = 04/01/2014和
  • end_period_date = 03/14/2014
  • (其中end_period_date在 begin_period_date之前发生

表级捕获无效数据关系并抛出最初使用源表创建的检查约束错误。

但是IS: BRAVO_UNIT_TIMETABLE_CK1 ?什么是 ORA-02290 ?如果您已经开发了一个APEX应用程序,以便分发给没有SQL级别访问相关数据表的任何人,那么这对您的最终用户来说是一个死胡同。在这种情况下部署,对于开发人员或技术人员而言,这只是另一个分心,他们最终会通过支持电话解释这一点。


如何设置APEX数据验证规则

设置页面级验证,该验证也可以捕获日期范围值的此要求:

Oracle Apex Page Processing Form Validation

在验证规则定义中,借用检查约束中使用的相同逻辑,但调整它以实现对PAGE FORM ITEMS的引用:

Oracle Apex Validation Logic for a Pair of Ranged Date Values

有很多方法可以配置验证规则,但有效的方法(来自此示例)是:

 Validation Type: PL/SQL Expression
 Validation Expression 1:

    CASE WHEN :P2_END_PERIOD_DATE > :P2_BEGIN_PERIOD_DATE OR
         :P2_END_PERIOD_DATE is NULL THEN TRUE
         ELSE FALSE
     END;

引用的变量特定于我的表单设计。 (根据您自己的设计需要进行修改)。


测试Apex表单验证

尝试使用以下相同类型的无效数据输入:

  • begin_period_date = 05/07/2014和
  • end_period_date = 03/04/2014
  • (其中end_period_date在 begin_period_date之前发生

以下是验证规则在执行实际DML命令之前捕获输入时Apex应用程序返回的内容:

通过APEX验证感染的无效表单条目的结果

Oracle Apex Data Entry With Date Range Validation

现在返回的错误消息看起来像最终用户可以自行解决的问题。这现在类似于OP的完整解决方案,因为它涉及Oracle数据库后端(重要)和前端(用户界面元素)。


结束思考

关于这篇文章主题的一些短暂的想法;它开启了一个关于软件开发参与者的热烈讨论,技术人员有时会厌恶地或忽视:最终用户

开发者的朋友,最终用户

最终用户有时是显而易见的,但它们贯穿于许多系统中。提供反馈或自助服务机制以使他们能够理解何时出错并立即如何纠正它是非常重要的。如果问题很难解决或者其管理员无法预料,相关和更新的联系信息应留在明显的视野中以获得进一步的帮助。

是的,但两种不同的验证规则是否多余?

验证规则在保护数据质量方面有两个不同的目的:

  • 数据库实际上正在服务于"完整性"通过维护系统要求的规则来约束(系统可以是围绕它的任意数量的应用程序和数据输入/输出)。在这种情况下,规则很简单:

    在这个系统中,人们不会及时倒退

  • 仅对数据库进行验证产生了一个神秘的回应。输入数据被阻止,满足数据质量要求。 Apex应用程序的要求,或者失败了,并且依赖于应用程序之外的支持以进一步解释。

冠。

答案 1 :(得分:1)

假设两列都是date类型,check约束将是

ALTER TABLE name_of_table
  ADD CONSTRAINT name_of_constraint
           CHECK( end_date > start_date );

请注意,这并未考虑在任一列中包含null值的可能性。如果end_date可能是null,那么您可能需要

ALTER TABLE name_of_table
  ADD CONSTRAINT name_of_constraint
           CHECK( end_date > start_date  or
                  end_date is null );