Забавно, но "температура кипения воды" и "температура, при которой кипит вода" - это вообще не одно и то же. Даже если давление воздуха ровно 1 атмосфера, и в сосуде имеется достаточно центров кипения, температура кипящей воды всё равно чуть выше 100 градусов. Иначе зачем бы ей вообще кипеть...
при нормальных условиях её температура будет уже какие-нибудь 105 градусов без кипения.
Хуже. В идеально чистой посуде, наполненной идеально чистой водой, нагреть можно до взрывного кипения, при котором реально из посуды вылетает практически всё (конечно, бОльшая часть в виде брызг). Сам такое проделывал. К сожалению, замерить температуру не получалось - термометр сам работал как точка кипения, ибо не идеально гладкий... а вот охладить воду без образования льда удавалось в термостате до минус 20 - а потом малейшее колебание, и почти весь объём обращается в лёд, стакан, понятное дело, в куски.
Нет смысла что то требовать от работников, этим вы по сути пытаетесь перенести отвественность за безопасность с себя на них
Да ну! то есть сотрудник в этом вопросе - вообще безответственный? позвольте не согласиться.
Я никакую ответственность ни на кого не переношу. Но я разграничиваю зоны ответственности - свою и работника. И считаю, что работник является полноценным участником процесса защиты. Точнее, должен являться - и пишу я именно о том, что в силу нулевой квалификации он зачастую просто неспособен на это.
есть ли в реляционных базах данных инструменты, аналогичные тому, что я описываю в статье? Например, инструмент помогающий найти функциональные зависимости, которые явно не видны. Или например рекомендующие нормализацию таблиц.
Реляционные БД предназначены для того, чтобы принимать данные, хранить их, обрабатывать и возвращать. И делать это эффективно. Так что указанный вами функционал никакого отношения к СУБД не имеет.
И да, такой инструмент на поверх СУБД вполне может быть создан. Как в составе ПО, которое включается в состав всего программного комплекса (возможности встроенного клиента, например), так и в виде создаваемого пользователем SQL-приложения либо независимого приложения, использующего СУБД в соответствии с его назначением.
Определение потенциальных ключей я беру классическое, т.е. не привязанное к базам данных.
Тем более. Именно привязка к базам данных и порождает ограничения, которых в случае классического определения быть и не должно. Просто классическое определение, как я понимаю, совсем не против переопределения данных и статических вычисляемых столбцов, а потому полагает, что любое выражение-кандидат нашло воплощение в виде отдельного столбца. То есть рассматривает вопрос с точки зрения "провёл глазом, и сразу заметил".
Потенциальные ключи таблицы (candidate key) - это наборы столбцов, которые обеспечивают уникальность каждой строчки таблицы. ...
Первичный ключ таблицы (primary key) - это то, про что рассказывает плоская таблица. ... Первичный ключ обеспечивает уникальность каждой строчки. Т.е. первичный ключ - это один из потенциальных ключей. ...
Это не совсем правильно. Вот простейший пример, который противоречит написанному:
CREATE TABLE test (id TEXT, PRIMARY KEY (id(10)));
Потенциальным ключом может быть не только набор столбцов, но и включающее их выражение. Да, не каждое выражение может быть первичным ключом, есть ограничения... но кандидатом - запросто.
Функциональные зависимости (functional dependencies).
Пардон, а какое отношение это имеет к понятию "Архитектура плоской таблицы"? То, что вы описываете - это внешние ключи, связи между таблицами, понятие уровня схемы данных... да элементарно требует минимум двух таблиц (даже в случае self-reference, когда это две копии одной таблицы).
Ааа... так это просто пример неудачный! Вот если бы базово рассматривалась именно заливка данных извне (грубо - контрагент прислал список записанных им на выезде потенциальных обучающихся, к примеру), где по определению может быть не всё ладно, тогда было бы сразу понятно, почему возможные проблемы проще именно допустить, а их причину проанализировать - потому что на каждую возможную граблю никаких запросов не хватит.
А ещё лучше, если бы рассматривалась именно проблема "кривого" запроса - да хоть с опечаткой. Это я к тому, что возможно в наборе добавляемых данных наличие просто кучи приводящих к ошибке ляпов, но отловится только один из них, а остальные - лишь после исправления, на следующем запуске. Почему и ратую за то, чтобы хотя бы самые очевидные из таких ляпов не допускались самОй логикой кода.
При сохранении записи на курс со ссылкой на студента, которого больше нет в БД, мы получим ошибку ограничения внешнего ключа. По хорошему на сервере нужно было заранее об этом подумать и сделать каскадное удаление данных, чтобы вообще не допускать этой проблемы.
Вот как-то совсем не понял, как вообще может возникнуть эта ошибка... если студента в БД нет, откуда взялась запись, которую вы пытаетесь сохранить? как она вообще могла появиться?
Со стороны интерфейса, как я понимаю, оно выглядит так: ткнули в студента, ткнули в курс, нажали кнопку "записать выбранного студента на выбранный курс". И описанная проблема может возникнуть только в случае, если с момента загрузки списков, пока расставляются галки, кто-то другой этого выбранного студента удалил.
Ну так это не проблема внешнего ключа, это проблема непродуманного алгоритма многопользовательской работы. Достаточно изменить запрос с простого, но ничего не проверяющего
INSERT INTO Registrations (StudentID, CourseID) VALUES (@StudentID, @CourseID);
на надёжное
INSERT INTO Registrations (StudentID, CourseID)
SELECT Students.StudentID, Cources.CourseID
FROM Students
CROSS JOIN Cources
WHERE Students.StudentID = @StudentID
AND Cources.CourseID = @CourseID;
И, собственно, всё. Ошибка умерла, даже не родившись. А, посмотрев на affected rows, можно сказать, успешно выполнена запись, или кто-то успел студента удалить.
Да, также вообще не понял, каким тут боком каскадное удаление. Так, для красного словца? Мы же вроде вставляем новую запись...
вы сказали что я не прав и привели подтверждение моих слов
Уточняю. Сортировка НЕ ОБЯЗАНА совпадать. Даже если она совершенно НЕ совпадает - всё равно использование индекса может настолько снизить объём просматриваемых данных, что это приведёт к ускорению выполнения запроса. Индекс сам по себе в большинстве случаев компактнее самОй таблицы.
Чтобы сделать выборку из огромного объёма данных нужно перебрать этот объём.
Если мы хотим избежать пункта 1, то мы должны хранить данные в э... сортированном виде, сортировка должна совпадать с требуемой выборкой.
В базах данных пункт 2 решается при помощи индексов.
Вы не совсем правы. Просто в качестве примера приведу покрывающий индекс, сортировка в котором запросто может не совпадать со сколько-нибудь подходящей для выполнения запроса - но тем не менее индекс ускоряет выполнение.
То есть индекс в первую голову используется в качестве компактной версии данных - читается не всё, а только (или по большей части) необходимое. А если ещё и сортировка подходящая - так это считай бонус.
Все определения совершенно единодушны в одном моменте - отсутствии согласия получить эту рассылку.
В то же время
я подписался на рассылку сообщений от госуслуг
и в этом согласии не было никаких запретов либо исключений на отдельные типы рассылки, которые бы позволили для данной конкретной рассылки утверждать, что она направлена без согласия на неё. Если нет частного правила, применяется общее. А общее - это согласие на рассылку.
Оснований для претензии не будет найдено.
PS. А вот мне почему-то такая рассылка не приходила. Наверное, потому что я не дал согласия на рассылку...
Запрещена "популяризация VPN-сервисов" и "использование VPN-сервисов для обхода блокировок".
Отдельное "популяризация VPN-сервисов" - это тоже вольная трактовка. Обход блокировки, описанный хотя бы как дополнительная возможность - это обязательное требование для трактования информации как подлежащей блокированию. Простая популяризация, где аргументы - это защищённость, конфиденциальность и прочие резоны, и ни полслова об обходе блокирования и получении доступа к противоправному контенту,- под закон не подпадают.
По моему личному опыту, всё куда как хуже. Хотя, может, мне так "везёт" на рабочие места. Но абсолютно везде я сталкиваюсь с крайне низким, близким к нулевому, уровнем общей компьютерной грамотности. Обычное дело - сотрудник минимум половину рабочего времени проводит за компьютером, при этом не зная (тем более не понимая) и, увы, не желая узнавать даже самые элементарные основы. Какое обучение ИБ? о чём вы? да такой, хоть три раза ему расскажи, просто не поймёт, с кем это ты сейчас разговаривал! Самое обидное, что порой, и даже не редко, это нежелание настолько явное, что сотрудник даже не стесняется открыто заявлять "не хочу и не буду учиться, у меня своей работы хватает". Не смущает даже прямое указание на то, что компьютер у него основной рабочий инструмент, а кто не умеет работать со своим основным рабочим инструментом - просто профнепригоден. Не, как об стенку горох. И руководителям - они сами обычно такие же, да плюс возраст. А обучение денег стОит, и от работы отвлекает. Инструкция? да она выветривается из головы ещё до того, как дочитана до конца. Инцидент? да, скорее всего напугает, да, скорее всего заставит немного задуматься... ага, только область действия - до дверей кабинета. Максимум, в рамках отдела.
Когда нет основ, самой-самой базы, никакой чек-лист не поможет. А если ещё и поддержки на самом верху у руководства нету, то единственное, что остаётся - делать всё тебе лично доступное, и ждать, когда же оно всё-таки ахнет.
Ну такой подход тоже имеет право на существование. Ок.
Автор пообещал ещё одну статью, с описанием "о последствиях". Надеюсь, там будет и анализ различий, и раскрытие условия/причины описанных катастрофических последствий. Подождём...
Не, не бывает. Хоть где-то, хоть у кого-то, хоть что-то, но непременно пойдёт не так и потребует адаптации. А уж от перехода с 14 на 15 версию Постгресса, где изменения вовсе не косметические, ожидать обратной совместимости в озвученной вами версии - это вообще верх оптимизма.
И да, вы так и не ответили на вопрос - как именно вы себе представляете ввод новой возможности, которой вообще ранее не существовало? Просто сообщите, что теперь вот есть такой оптимизированный метод, но он не по дефолту и надо включать непременно явно и руками? Ну допустим... а когда, по-вашему, сделать его дефолтным? в 16-й версии? В 17-й? но тогда, по вашему определению, именно в этой версии будет наблюдаться "нарушение обратной совместимости". То есть этого "нарушения" никак не избежать! ну давайте по максимум оттягивать, да? а если глазки ладошками прикрыть, так этого изменения, может, и вовсе нету?
Да практически каждая версия что-то где-то меняет в настройках по умолчанию. А то и вовсе объявляет что-то deprecated. Или вообще что-то, о ужас, удаляется. Какая уж тут обратная совместимость, ведь из-за этого у кого-нибудь что-то да непременно взбрыкнёт. И ничего, это как-то не препятствует считать, что продукты поддерживают обратную совместимость. Чем тут Постгресс такой особенный?
Простите, а как, по-вашему, оно должно было быть сделано?
Вот введена новая, ранее не существовавшая, технология выполнения некоей операции. Соответственно расширился синтаксис. И по умолчанию, вполне очевидно, используется более эффективный новый вариант.
А что вы предлагаете? В угоду тем, кто, переползая на новую версию, не удосуживается прочитать всё о вводимых дополнениях и изменениях, и соответственно не корректирует свои данные и метаданные, использовать по умолчанию менее эффективную опцию? Да вряд ли. Во-первых, таковых пользователей, как ни крути, меньшинство, во-вторых, далеко не у каждого невнимательного/ленивого возникнут проблемы, даже если он ничего не будет делать.
Разработчики ни полслова не говорят о том, что имевшийся ранее алгоритм удалён или изменён. Я думаю, что если там и есть какие корректировки, то чисто косметические. Соответственно синтаксис позволяет при указании соотв. опций использовать ранее существовавший алгоритм действий. А это, в свою очередь, означает, что никаких проблем с обратной совместимостью нет.
Обратная совместимость - она да, требует, чтобы работало. Но не требует, чтобы при этом можно было даже пальцем не шевелить. Хоть и не очень люблю, но процитирую Вики:
Обра́тная совмести́мость — наличие в новой версии компьютерной программы или компьютерного оборудования интерфейса, присутствующего в старой версии, в результате чего другие программы (или человек) могут продолжать работать с новой версией без значительной переделки (или переучивания).
То есть, как видите, необходимость переделки и/или переучивания - она даже не обсуждается. Просто объём таких изменений должен быть вменяемый, как говорится, "без фанатизма".
Ну давайте не будем "стильно, модно, молодежно (по новому стандарту SQL)", а напишем в стиле "как было изначально задумано (Oracle-ом)".
Берём, значит, старый, кондовый, совершенно валидный (и, как обычно, совершенно уникальный) для Оракла синтаксис:
Select date '2024-02-29' - interval '2-0' year(1) to month from dual
Что? опять ORA-01839: date not valid for month specified ?
Не, не в новом стандарте дело, оказывается. И косяк у него с вполне себе старым механизмом работы с датами. Просто раньше оно никому не попадалось под руку.
Как бы вы решали такую задачу? Предположим, есть таблица с купонами, и у купонов есть некая дата устаревания valid_until. Вам надо обеспечить такое ограничение (constraint) на уровне БД, чтобы у одного человека мог быть только один действующий купон.
Я бы, наверное, сразу объявил задачу недоопределённой. Вполне жизненная ситуация - у меня есть два купона, оба в будущем, причём пересекающиеся. Я хочу оба зарегистрировать, а впоследствии, но до начала их действия, от одного отказаться. В реальности всё проще - из всех актуальных берём наиболее выгодный, и дело с концом..
Нет, просто как контроль на отсутствие пересекающихся диапазонов - всё прекрасно. А вот сам пример для демонстрации методы - какой-то не очень... уж лучше бы придумать... ну я не знаю, дополнительная банка пива в самолёте - в двух-то одновременно ну никак не полететь.
Забавно, но "температура кипения воды" и "температура, при которой кипит вода" - это вообще не одно и то же. Даже если давление воздуха ровно 1 атмосфера, и в сосуде имеется достаточно центров кипения, температура кипящей воды всё равно чуть выше 100 градусов. Иначе зачем бы ей вообще кипеть...
Хуже. В идеально чистой посуде, наполненной идеально чистой водой, нагреть можно до взрывного кипения, при котором реально из посуды вылетает практически всё (конечно, бОльшая часть в виде брызг). Сам такое проделывал. К сожалению, замерить температуру не получалось - термометр сам работал как точка кипения, ибо не идеально гладкий... а вот охладить воду без образования льда удавалось в термостате до минус 20 - а потом малейшее колебание, и почти весь объём обращается в лёд, стакан, понятное дело, в куски.
Да ну! то есть сотрудник в этом вопросе - вообще безответственный? позвольте не согласиться.
Я никакую ответственность ни на кого не переношу. Но я разграничиваю зоны ответственности - свою и работника. И считаю, что работник является полноценным участником процесса защиты. Точнее, должен являться - и пишу я именно о том, что в силу нулевой квалификации он зачастую просто неспособен на это.
Реляционные БД предназначены для того, чтобы принимать данные, хранить их, обрабатывать и возвращать. И делать это эффективно. Так что указанный вами функционал никакого отношения к СУБД не имеет.
И да, такой инструмент на поверх СУБД вполне может быть создан. Как в составе ПО, которое включается в состав всего программного комплекса (возможности встроенного клиента, например), так и в виде создаваемого пользователем SQL-приложения либо независимого приложения, использующего СУБД в соответствии с его назначением.
Тем более. Именно привязка к базам данных и порождает ограничения, которых в случае классического определения быть и не должно. Просто классическое определение, как я понимаю, совсем не против переопределения данных и статических вычисляемых столбцов, а потому полагает, что любое выражение-кандидат нашло воплощение в виде отдельного столбца. То есть рассматривает вопрос с точки зрения "провёл глазом, и сразу заметил".
Это не совсем правильно. Вот простейший пример, который противоречит написанному:
Потенциальным ключом может быть не только набор столбцов, но и включающее их выражение. Да, не каждое выражение может быть первичным ключом, есть ограничения... но кандидатом - запросто.
Пардон, а какое отношение это имеет к понятию "Архитектура плоской таблицы"? То, что вы описываете - это внешние ключи, связи между таблицами, понятие уровня схемы данных... да элементарно требует минимум двух таблиц (даже в случае self-reference, когда это две копии одной таблицы).
Эхх... ну хоть кто-то думает так же, как и я.
Ааа... так это просто пример неудачный! Вот если бы базово рассматривалась именно заливка данных извне (грубо - контрагент прислал список записанных им на выезде потенциальных обучающихся, к примеру), где по определению может быть не всё ладно, тогда было бы сразу понятно, почему возможные проблемы проще именно допустить, а их причину проанализировать - потому что на каждую возможную граблю никаких запросов не хватит.
А ещё лучше, если бы рассматривалась именно проблема "кривого" запроса - да хоть с опечаткой. Это я к тому, что возможно в наборе добавляемых данных наличие просто кучи приводящих к ошибке ляпов, но отловится только один из них, а остальные - лишь после исправления, на следующем запуске. Почему и ратую за то, чтобы хотя бы самые очевидные из таких ляпов не допускались самОй логикой кода.
Вот как-то совсем не понял, как вообще может возникнуть эта ошибка... если студента в БД нет, откуда взялась запись, которую вы пытаетесь сохранить? как она вообще могла появиться?
Со стороны интерфейса, как я понимаю, оно выглядит так: ткнули в студента, ткнули в курс, нажали кнопку "записать выбранного студента на выбранный курс". И описанная проблема может возникнуть только в случае, если с момента загрузки списков, пока расставляются галки, кто-то другой этого выбранного студента удалил.
Ну так это не проблема внешнего ключа, это проблема непродуманного алгоритма многопользовательской работы. Достаточно изменить запрос с простого, но ничего не проверяющего
на надёжное
И, собственно, всё. Ошибка умерла, даже не родившись. А, посмотрев на affected rows, можно сказать, успешно выполнена запись, или кто-то успел студента удалить.
Да, также вообще не понял, каким тут боком каскадное удаление. Так, для красного словца? Мы же вроде вставляем новую запись...
Уточняю. Сортировка НЕ ОБЯЗАНА совпадать. Даже если она совершенно НЕ совпадает - всё равно использование индекса может настолько снизить объём просматриваемых данных, что это приведёт к ускорению выполнения запроса. Индекс сам по себе в большинстве случаев компактнее самОй таблицы.
Вы не совсем правы. Просто в качестве примера приведу покрывающий индекс, сортировка в котором запросто может не совпадать со сколько-нибудь подходящей для выполнения запроса - но тем не менее индекс ускоряет выполнение.
То есть индекс в первую голову используется в качестве компактной версии данных - читается не всё, а только (или по большей части) необходимое. А если ещё и сортировка подходящая - так это считай бонус.
Все определения совершенно единодушны в одном моменте - отсутствии согласия получить эту рассылку.
В то же время
и в этом согласии не было никаких запретов либо исключений на отдельные типы рассылки, которые бы позволили для данной конкретной рассылки утверждать, что она направлена без согласия на неё. Если нет частного правила, применяется общее. А общее - это согласие на рассылку.
Оснований для претензии не будет найдено.
PS. А вот мне почему-то такая рассылка не приходила. Наверное, потому что я не дал согласия на рассылку...
Отдельное "популяризация VPN-сервисов" - это тоже вольная трактовка. Обход блокировки, описанный хотя бы как дополнительная возможность - это обязательное требование для трактования информации как подлежащей блокированию. Простая популяризация, где аргументы - это защищённость, конфиденциальность и прочие резоны, и ни полслова об обходе блокирования и получении доступа к противоправному контенту,- под закон не подпадают.
По моему личному опыту, всё куда как хуже. Хотя, может, мне так "везёт" на рабочие места. Но абсолютно везде я сталкиваюсь с крайне низким, близким к нулевому, уровнем общей компьютерной грамотности. Обычное дело - сотрудник минимум половину рабочего времени проводит за компьютером, при этом не зная (тем более не понимая) и, увы, не желая узнавать даже самые элементарные основы. Какое обучение ИБ? о чём вы? да такой, хоть три раза ему расскажи, просто не поймёт, с кем это ты сейчас разговаривал! Самое обидное, что порой, и даже не редко, это нежелание настолько явное, что сотрудник даже не стесняется открыто заявлять "не хочу и не буду учиться, у меня своей работы хватает". Не смущает даже прямое указание на то, что компьютер у него основной рабочий инструмент, а кто не умеет работать со своим основным рабочим инструментом - просто профнепригоден. Не, как об стенку горох. И руководителям - они сами обычно такие же, да плюс возраст. А обучение денег стОит, и от работы отвлекает. Инструкция? да она выветривается из головы ещё до того, как дочитана до конца. Инцидент? да, скорее всего напугает, да, скорее всего заставит немного задуматься... ага, только область действия - до дверей кабинета. Максимум, в рамках отдела.
Когда нет основ, самой-самой базы, никакой чек-лист не поможет. А если ещё и поддержки на самом верху у руководства нету, то единственное, что остаётся - делать всё тебе лично доступное, и ждать, когда же оно всё-таки ахнет.
Полагаете, что сайт Каспера заблокируют за описание настройки Kaspersky Security Network? Прокся, облачная, защищённая да пошифрованная...
Почитайте критерии - описание процесса настройки среди них ну вовсе даже не определяющий.
Вот где-то тут опечатка, нутром чую...
И вычитайте перевод - ну за версту ж видно ляпсусы. "Параллельное оптоволокно"... А уж таблички так и вовсе..
Ну такой подход тоже имеет право на существование. Ок.
Автор пообещал ещё одну статью, с описанием "о последствиях". Надеюсь, там будет и анализ различий, и раскрытие условия/причины описанных катастрофических последствий. Подождём...
Не, не бывает. Хоть где-то, хоть у кого-то, хоть что-то, но непременно пойдёт не так и потребует адаптации. А уж от перехода с 14 на 15 версию Постгресса, где изменения вовсе не косметические, ожидать обратной совместимости в озвученной вами версии - это вообще верх оптимизма.
И да, вы так и не ответили на вопрос - как именно вы себе представляете ввод новой возможности, которой вообще ранее не существовало? Просто сообщите, что теперь вот есть такой оптимизированный метод, но он не по дефолту и надо включать непременно явно и руками? Ну допустим... а когда, по-вашему, сделать его дефолтным? в 16-й версии? В 17-й? но тогда, по вашему определению, именно в этой версии будет наблюдаться "нарушение обратной совместимости". То есть этого "нарушения" никак не избежать! ну давайте по максимум оттягивать, да? а если глазки ладошками прикрыть, так этого изменения, может, и вовсе нету?
Да практически каждая версия что-то где-то меняет в настройках по умолчанию. А то и вовсе объявляет что-то deprecated. Или вообще что-то, о ужас, удаляется. Какая уж тут обратная совместимость, ведь из-за этого у кого-нибудь что-то да непременно взбрыкнёт. И ничего, это как-то не препятствует считать, что продукты поддерживают обратную совместимость. Чем тут Постгресс такой особенный?
Простите, а как, по-вашему, оно должно было быть сделано?
Вот введена новая, ранее не существовавшая, технология выполнения некоей операции. Соответственно расширился синтаксис. И по умолчанию, вполне очевидно, используется более эффективный новый вариант.
А что вы предлагаете? В угоду тем, кто, переползая на новую версию, не удосуживается прочитать всё о вводимых дополнениях и изменениях, и соответственно не корректирует свои данные и метаданные, использовать по умолчанию менее эффективную опцию? Да вряд ли. Во-первых, таковых пользователей, как ни крути, меньшинство, во-вторых, далеко не у каждого невнимательного/ленивого возникнут проблемы, даже если он ничего не будет делать.
Разработчики ни полслова не говорят о том, что имевшийся ранее алгоритм удалён или изменён. Я думаю, что если там и есть какие корректировки, то чисто косметические. Соответственно синтаксис позволяет при указании соотв. опций использовать ранее существовавший алгоритм действий. А это, в свою очередь, означает, что никаких проблем с обратной совместимостью нет.
Обратная совместимость - она да, требует, чтобы работало. Но не требует, чтобы при этом можно было даже пальцем не шевелить. Хоть и не очень люблю, но процитирую Вики:
То есть, как видите, необходимость переделки и/или переучивания - она даже не обсуждается. Просто объём таких изменений должен быть вменяемый, как говорится, "без фанатизма".
Ну давайте не будем "стильно, модно, молодежно (по новому стандарту SQL)", а напишем в стиле "как было изначально задумано (Oracle-ом)".
Берём, значит, старый, кондовый, совершенно валидный (и, как обычно, совершенно уникальный) для Оракла синтаксис:
Select date '2024-02-29' - interval '2-0' year(1) to month from dualЧто? опять ORA-01839: date not valid for month specified ?
Не, не в новом стандарте дело, оказывается. И косяк у него с вполне себе старым механизмом работы с датами. Просто раньше оно никому не попадалось под руку.
Я бы, наверное, сразу объявил задачу недоопределённой. Вполне жизненная ситуация - у меня есть два купона, оба в будущем, причём пересекающиеся. Я хочу оба зарегистрировать, а впоследствии, но до начала их действия, от одного отказаться. В реальности всё проще - из всех актуальных берём наиболее выгодный, и дело с концом..
Нет, просто как контроль на отсутствие пересекающихся диапазонов - всё прекрасно. А вот сам пример для демонстрации методы - какой-то не очень... уж лучше бы придумать... ну я не знаю, дополнительная банка пива в самолёте - в двух-то одновременно ну никак не полететь.