CREATE TABLE `scheduler` (
  `id` INT NOT NULL, 
  `user_id` INT NOT NULL, 
  `s_year` INT NOT NULL, 
  `s_month` INT NOT NULL, 
  `s_day` INT NOT NULL, 
  `s_wday` INT NOT NULL,
  PRIMARY KEY (`id`)
);

Установленные неотрицательные значения полей определяют периодичность выполнения задания. Например, следующим запросом можно найти все задания пользователя, которые должны быть выполнены текущим днем -- включая одноразовые (указаны год-месяц-день) и периодические (в заданный день месяца или день недели). Это примерное решение. Возможно еще требует доработки.

SELECT 
    s_year - EXTRACT(YEAR FROM NOW()) as x_year, 
    s_month - EXTRACT(MONTH FROM NOW()) as x_month, 
    s_day - EXTRACT(DAY FROM NOW()) as x_day, 
    s_wday - WEEKDAY(NOW()) - 1 as x_wday, 
    id 
FROM 
    scheduler
WHERE 
    user_id=0
HAVING 
    x_wday = 0
    OR (
        x_day = 0 OR x_month = 0 OR x_year = 0
    )

Забыл упомянуть, что сей пример написан на MySQL 4.

Spy00000 пишет:

rem_type - тип напоминания (1 - однократное, 2 - в опр. день недели, 3 - в опр. день месяца, 4 - на третий день после очередного финансового кризиса, и т.д.)
rem_num (число) - доп. параметр, зависит от rem_type, для 1 - не используется, для 2 - день недели, когда срабатывать, для 3 - день месяца и т.д.)

для 1 - не используется - НЕТ !!!  Тогда для rem_type=1 в rem_num должна стоять дата !

Дата тогда уже будет стоять в date, зачем ей ещё в rem_num?

Имхо, вычислять лучше в момент создания задания и в момент срабатывания. Скрипты лишние запускать не надо будет регулярно.

Тут смотреть надо, какие вообще типы напоминаний будут. Если несколько дней только в "в определённый день недели" - можно в rem_num держать битовую маску дней. Иначе что-то сложнее выдумывать.

Тему прошу оставить, мало ли из башки вылетит - подгляжу...

rem_type - тип напоминания (1 - однократное, 2 - в опр. день недели, 3 - в опр. день месяца, 4 - на третий день после очередного финансового кризиса, и т.д.)
rem_num (число) - доп. параметр, зависит от rem_type, для 1 - не используется, для 2 - день недели, когда срабатывать, для 3 - день месяца и т.д.)

для 1 - не используется - НЕТ !!!  Тогда для rem_type=1 в rem_num должна стоять дата !

Дальше поля зависят от того, как должно напоминаться.
Пока предположим - как в outlook, только текст, без всяких запусков внешних программ и прочего. Тогда просто:

text - текст напоминания.

Алгоритм работы такой:
При создании задания на основе текущей даты и rem_type, rem_num, rem_time выбирается дата очередного срабатывания.
К примеру: сегодня 2011-08-19, rem_type = 2, rem_num = 6 (суббота), rem_time = 15:00, тогда очередная дата срабатывания - 2011-08-20 15:00, что и заносится в date.

После чего таблица регулярно (раз в секунду, в 5 секунд, раз в месяц) проверяется и если у какого-то задания date < текущей даты - выводится напоминание
и генерируется новая дата напоминания. Задания с rem_type == 1 просто удаляются.

Можно ввести ещё поле - активное или не активное задание, тогда задания с rem_type == 1 нужно не удалять, а делать неактивными.
Дальше - простор фантазии.

Дополнительно:
Если пользователь сам заходит на страницу, тогда проверять таблицу при входе пользователя.

Если нужна дата окончания, я бы предложил держать всё в одной таблице, добавить флаг - "есть дата окончания", поле "дата окончания" и при генерации очередной даты срабатывания проверять, чтобы она не была больше "дата окончания", иначе делать задание неактивным.
А дату начала учитывать при генерации даты первого срабатывания.

Разрабатываю WEB органайзер для ~150 пользователей, одной из его функций будет напоминалка по расписанию. Вот в этой напоминалке и застрял с разработкой структуры базы и своими хотелками...
Хочу, много...   хочу чтобы можно было напоминать по каждому дню недели, по каждому числу месяца, в заданный день года, по каждому понедельнику (дню недели), по каждому 20-му числу каждого месяца....  вообще всяко хочу...

Но как под такую хотелку разработать структуру базы ?