Люди, которые «знают» SQL, будут искать декларативные решения и избегать процедурного кода.Пометка строк - это «запах» процедурного кода.
Является ли набор Items
статическим (никогда не изменяется) или стабильным (редко изменяется)?Если да, было бы проще выполнить одноразовое упражнение по генерации таблицы поиска значений с настоящего момента и до конца времени, вместо того, чтобы планировать запуск процедуры ежедневно, чтобы искать неиспользуемые флаги и обновлять флаг на сегодня и очищатьвсе флаги, если все они использовались и т. д.
Создайте таблицу последовательных дат между сегодняшним днем и датой далекого будущего, представляющих время жизни вашего приложения (вы, конечно, можете рассмотреть возможность исключения нерабочих дней)Добавьте столбцы, ссылающиеся на ключ в вашей таблице Items
(убедитесь, что вы выбрали ON DELETE NO ACTION
ссылочное действие на тот случай, если эти Items
окажутся не статичными!) Затем случайным образом назначьте весь набор Items
одинв день, пока каждый не был использован один раз.Повторите еще раз для всего набора Items
, пока таблица не заполнится.Вы можете легко сгенерировать эти данные, используя электронную таблицу, и импортировать их (или чистый SQL, если вы хардкор;)
Быстрый пример с использованием стандартного SQL:
Скажем, в пять только Items
set:
CREATE TABLE Items
(
item_ID INTEGER NOT NULL UNIQUE
);
INSERT INTO Items (item_ID)
VALUES (1),
(2),
(3),
(4),
(5);
Ваша таблица поиска будет такой простой:
CREATE TABLE ItemsOfTheDay
(
cal_date DATE NOT NULL UNIQUE,
item_ID INTEGER NOT NULL
REFERENCES Items (item_ID)
ON DELETE NO ACTION
ON UPDATE CASCADE
);
Начиная с сегодняшнего дня, добавьте весь набор Items
в случайном порядке:
INSERT INTO Items (item_ID)
VALUES ('2010-07-13', 2),
('2010-07-14', 4),
('2010-07-15', 5),
('2010-07-16', 1),
('2010-07-17', 3);
Затем, начиная с самой последней незаполненной даты, добавьте весь набор Items
в (мы надеемся, в другом) случайном порядке:
INSERT INTO Items (item_ID)
VALUES ('2010-07-18', 1),
('2010-07-19', 3),
('2010-07-20', 4),
('2010-07-21', 5),
('2010-07-22', 2);
... и снова ...
INSERT INTO Items (item_ID)
VALUES ('2010-07-23', 2),
('2010-07-24', 3),
('2010-07-25', 5),
('2010-07-26', 1),
('2010-07-27', 4);
.. и т. Д. До тех пор, пока таблица не заполнится.
Тогда это будет просто случай поиска сегодняшней даты в таблице поиска по мере необходимости.
Если набор Items
изменится, то таблицу поиска, очевидно, необходимо будет регенерировать, поэтому вам необходимо сбалансировать простоту конструкции с необходимостью ручного обслуживания.