Comments 15
В Oracle достаточно много "особенностей" при работе с датами. Все эти add_months, interval и прочие имеют каждый свои грабли и область применения. Я не считаю верным строить экзамен, как преодоление полосы препятствий через ряд неочевидных грабель в дефиците времени.
Я подозреваю обо всех граблях рассказывали на лекциях и проблема во внимательности, а не в поиске граблей.
Я подозреваю, что вы не в теме количества граблей в Oracle. И с каждой версией появляются новые. Лучше бы на лекциях про полезные вещи рассказывали, а не про очередные грабли :-)
Не понимаю как связаны все грабли в Oracle и грабли для задания к экзамену, которые скорее всего проработали на лекциях?
Я тоже учился у этого преподавателя, в защиту автора скажу, действительно, о 'граблях' узнаешь только во время сдачи экзамена/лабораторных. Во время лекции зачастую эти вопросы не обсуждаются.
Здесь от личного отношения препода зависит, может завалить такой проверкой, а может и нет... К сожалению, это задание лишь одно из многих, на которых можно отлично научиться писать костыльные запросы.
Я бы подумал - стоит ли продолжать учиться в университете, где на экзамене спрашивают такую хрень, да еще и зависимую от производителя БД. При этом, думаю, реальные проблемы вроде нормализации БД под разные задачи, сегментирования, выбора типа индекса, оценки и оптимизации запросов - скорее всего оказались обойдены стороной.
Отличный пример того, каким не должно быть задание.
Если есть подобная проблема (?), об этом должно было быть указано в задании.
Студент не обязан знать, что случается в начале эпохи с современной СУБД. Но если бы этот аспект был указан в задании, то всё встало бы на свои места.
Мне кажется, проблема в позиционировании задачи. То есть, она про шашечки или ехать?
Сожно спросить: "Зачем в принципе смотреть даты раньше X (или даже XIX) века?". Ответы в стиле "должно работать с любой датой" - это утопия. Этот путь приведет туда, куда пришли вы - вставка в запрос костылей для особенностей учета времени в стародавние времена. Нулевой год - это только цветочки. Например, нужно учитывать, в каком году страна перешла на григорианский календарь (страны мира переходили на него более более 400 лет). А для более ранних дат введены специальные календари. И там другие правила учета високосного года.
Ответы в стиле "интересно" или "почему нет?" - это более понятно. В этом случае можно не вставлять костыли. Можно просто сказать "Запрос отлично справляется с датами от такого-то года. А до этого года вылезают разные баги, вызванные историческими причинами."
Интересно, приведенное решение учитывает, что 1896 високосный, а 1900 - нет?
По этой же причине интересно узнать о выборе 420 года.
Это ещё перевода на зимнее/летнее время не было в задаче! </sarcasm>
Часто встречал, что нижнюю границу задают явно 01/01/1900, верхнюю - 01/01/4000.
Как-то поймали "магию" при обработке дат/времени 01/01/1970 на Java (учет часовых поясов и перевода на летнее/зимнее время) и сменили нижнюю границу на 01/01/1970.
Передаю пламенный привет из 2022 года с прикладной информатики в Политехническом. Да, все еще ничего не поменялось
Бегите из этой богадельни туда, где обьясняют - почему для разных задач подходят БД разной архитектуры и разные схемы, как масштабировать БД для высоких нагрузок и/или большого обьема данных, как работают транзакции и когда от них лучше отказаться - и так далее. Или учите сами - потому что там вас научат максимум каким-то хитровыдуманным трюкам, абсолютно бесполезным в реальной работе.
Нулевой год в БД Oracle