Проверить ограничение, чтобы убедиться, что дата не в будущем?

Question

Я пытаюсь создать таблицу, в которой записываются изменения, внесенные в приблизительные часы другой таблицы.База данных в целом является системой управления проектами для компании, чтобы назначить работу своим сотрудникам и создать счета для клиента.

В настоящее время у меня есть:

CREATE TABLE task_history
(
    task_history_id         NUMBER(5),
    previous_est_hours      NUMBER(3,1),
    change_date         DATE,
    reason_for_change       VARCHAR2(50),
    task_id             NUMBER(5),

CONSTRAINT TASKHIST_TASKHISTID_PK   PRIMARY KEY (task_history_id),
CONSTRAINT TASKHIST_TASKID_FK       FOREIGN KEY (task_id) REFERENCES task(task_id),
CONSTRAINT TASKHIST_TASKID_NN CHECK (task_id IS NOT NULL),
CONSTRAINT TASKHIST_CHANGEDATE_NONFUTURE CHECK (change_date <= sysdate)
);

change_date не должнобудущая дата, это должно быть либо сегодня, либо в прошлом.Последнее ограничение проверки является проблемой.Насколько я понимаю, вы не можете использовать sysdate по причине, которую я забыл, но вы не можете.Я также попробовал GETDATE () и любой другой вариант, который я нашел в Интернете.Как я могу сделать это, по-видимому, простое задание?

Answer 1

Вы не можете вызывать функцию из проверочного ограничения, поэтому наиболее естественным подходом будет определение триггера для таблицы task_history, т.е.

CREATE OR REPLACE TRIGGER task_change_date_in_past
  BEFORE INSERT OR UPDATE ON task_history
  FOR EACH ROW
BEGIN
  IF( :new.change_date > sysdate )
  THEN
    RAISE_APPLICATION_ERROR( -20001, 'Change date must be in the past' );
  END IF;
END;

Answer 2

В 11g можно использовать проверочные ограничения с sysdate: http://rwijk.blogspot.com/2007/12/check-constraints-with-sysdate.html

До 11g вы должны использовать подход Джастина.

С уважением,
Роб.

Answer 3

CONSTRAINT TASKHIST_CHANGEDATE_NONFUTURE CHECK (change_date <= sysdate)

Это было бы действительно проблематично в качестве Ограничения. Подумайте, что произойдет, если нужно обновить строку (какой-то другой столбец) или деактивировать / реактивировать ограничение. Он не будет сравниваться с исходной датой, но с current SYSDATE!

Я бы рекомендовал добавить в таблицу еще один столбец со значением по умолчанию SYSDATE и создать ограничение или TRIGGER, который будет сравнивать новый столбец (сохраненный SYSDATE) с изменением даты.

Answer 4

Я думаю, что вы можете определить пользовательскую функцию, которая выполняет эту проверку, и использовать ее в проверочном ограничении.