PD>>По-видимому, в тот момент, когда нужно добавить данные на апрель. А кто будет вызывать для исходного расписания и когда ? S>Как определить момент, когда "нужно добавить данные на апрель"? Получается, расписание должно быть не пассивной сущностью, которая просто отвечает на вопрос "когда ближайший День Космонавтики", но ещё и чуть ли не активной штукой (потоком), которая раз в X просыпается и добавляет новые данные.
Ты не ответил на вопрос "кто будет вызывать для исходного расписания и когда". Поскольку ответа нет, домыслю сам.
Если ты хочешь расписание на неопределенный период, то так, конечно, не получится. Вечную иглу Остапа Бендера так не сделать. Вот только боюсь, что он был прав — он не собирался жить вечно.
Напомню, что исходным для меня было расписание авиарейсов. А оно меняется кардинально раз в полгода, по крайней мере в Омском аэропорту. Есть зимнее и есть летнее. Плюс точечные коррекции и того и другого во время сезона.
Кстати, в моем варианте для студентов был и такой способ задания дат предумотрен. Просто фиксированный набор дат, как это с самолетами и бывает нередко. Не по вторникам или ежедневно, а просто "1, 4, 12 и 23 января". Тут растеризация не нужна, данные уже растеризованы, нужно лишь их проверить на дубликаты. И вечное такое расписание сделать никак нельзя.
Расписание, скажем, занятий на курсе тоже меняется раз в полгода. В следующем семестре его делают заново.
Слишком много факторов, которые в итоге не позволяют делать такие вещи на более или менее длительный период. Все равно придется что-то удалять, что-то добавлять, что-то заменять.
А если нужно продлить — просто отредактировать его, изменив срок окончания.
И все это будет делать человек. Больше некому.
Что за ивенты в конце концов , если это не такой уж большой секрет ? Сколько их в день может максимум быть на одного, скажем, юзера ? При миллионе записей в год, я уже писал, будет >500 в день. Увольте меня от таких ивентов, я не i7.
Ну а если тебе и впрямь нужно вечное расписание — поищи иную идею. Создавать таблицы БД с бесконечным числом строк я не предлагаю.
PD>>Верно. Только вот GetNextOccurence будет намного сложнее. S>Намного сложнее, чем что? Чем функция CreateXXX()? А почему?
Чем взятие SELECT TOP или аналогичный поиск по дереву.
Почему — ну напиши ее для варианта (ладно, дождичек оставим в покое и внешнюю зависимость тоже) — "в первый вторник ноября 2035 года в 0.00.". Код будет несложным, по под капотом будет лежать весь Григорианский календарь, да еще и наличие летнего времени, так как 0.00 12 ноября может оказаться и 23.00 11 ноября, а это уже не вторник.
S>Ну так там "перевычисление" стоит O(1). Что всё ещё гораздо лучше, чем O(Log(N)) в "оптимизированном" случае.
Вот только при этом будут опять же задействованы все алгоритмы календаря под капотом, которые, конечно, CO(n), но только С будет не такой уж малой.
PD>>Представь себе, что тебе нужно найти некую точку на экране (то есть в дискретном пространстве), через которую проходит некая y=f(x) при x1<x<x2. Ну хотя бы с min(y). Аналитически задача не решается. S>Зачем мне представлять себе аллегорию, которая не является удачным аналогом моей задачи? В расписаниях никогда не бывает так, чтобы событие с номером n+1 случилось бы раньше события с номером n.
PD>>2. предварительно записать в массив Point все точки (x,y) и искать в нем. S>Теперь понятно. Неверное решение следует из неверной аналогии.
Я не пойму, чего ради ты так агрессивно настроен. Я что, тебя заставляю делать так ? Я высказал свою точку зрения, можешь ее не принимать, бога ради.
