Rsa97

Просто вычти из "х" значение 69, тогда оно станет равно 54.

Правда, есть ещё одно подходящее значение х, чуть больше единицы, но его найти сложнее.

Когда каскадное обновление это плохо?

Каскадное обновление - в большинстве случаев это... глупо.

Вспомним, что это вообще такое.

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

По смыслу в основной таблице это поле - как минимум уникально. То есть с точностью до NULL оно является идентифицирующим - то есть если в этом поле не NULL, то определённое значение однозначно идентифицирует строго одну запись. В большинстве случаев же поле в основной таблице, на которое установлена ссылка в подчинённой таблице, вообще является первичным ключом, соответственно не может быть NULL и является истинно идентифицирующим.

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

Ну то, что изменение/корректировка значения поля первичного ключа есть bad practice (читай - дурь голимая), хорошо известно, обосновано и весьма логично. Нет, реально возможны ситуации, когда такая операция оправдана и имеет смысл - но такая ситуация абсолютно всегда одноразовая, и есть составная часть административного обслуживания. А если подобная надобность возникла на уровне пользователя, в рабочем процессе - то это гарантия наличия серьёзной ошибки в проектировании БД.

Практически всё то же относится и к корректировке просто уникального поля. За исключением случая, когда выполняется каскадное изменение значения поля, которое в основной таблице получило значение NULL. То есть когда выполняемая операция по смыслу является не обновлением, а "мягким удалением" основной записи с каскадным удалением всех подчинённых. Правда, на вопрос, как отличить мягко каскадно-удалённые подчинённые записи от мягко явно-удалённых, и как определить, с какой основной записью была связана мягко удалённая подчинённая, не залезая в журнал или бэкап, ответа никто не даст. А получается, что даже в случае исключения всё делается через "универсальный интерфейс", то есть косяк в проектировании структуры имеется и в этом случае.

Резюмирую. Если каскадное обновление необходимо, оно скорее всего маскирует недостатки и ошибки проектирования. А плохо это или хорошо - прикрывать дырку костылём,- решайте сами.

Вообще, dig считает что NS для citadel.crimea.ru -
ns1.ht-systems.ru.
ns2.ht-systems.ru.

а не рег.ру
Выглядит как недоперенесенный домен, отсюда и проблемы с записями

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

имхо тут эфир забит. Разнести устройства по частотам - часть унести на 2.4

В Asterisk такое можно сделать аж двумя способами (как минимум):
1. dialplan
а. Можно через curl послать запрос:
https://docs.asterisk.org/Asterisk_21_Documentatio...

б. Можно заранее сопоставление входящего номера - внутреннего запихнуть в базу и потом через DB() вытаскивать

в. Обратиться к произвольной базе через ODBC()

2. рядом поставить сервер, который будет подключаться по AMI и посылать Redirect команду при поступлении звонка (какое там событие - не помню)

Оба пути достаточно тяжелы. В одном случае тебе придётся писать монструозный диалплан и как-то интегрировать внешнюю систему с астериском.
В другом - придётся учить внешнюю систему подключаться к астериску и мучаться с AMI.

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

Никак

обычной встройки на материнке в 99% случаев будет достаточно

Rsa97 правильно написал про геометрический смысл. Но есть более быстрое решение за O(n log n), использующее метод заметающей прямой.

Пересеките все прямоугольники с тем, который надо покрыть, отрезав от них торчащую наружу часть.

Если числа в задаче большие или нецелые, то сначала через бинпоиск или хешмап замените все координаты по X и по Y на их порядковый номер в отсортированном массиве (отдельно по каждой оси). Эта операция называется "сжатие координат". Теперь у вас все координаты целые числа от 0 до 2*n.

Потом примените алгоритм "заметающей прямой". Представьте, что вертикальная линия двигается слева-направо и "заметает" картинку. Вам надо отслеживать, какие прямоугольники ее пересекают в каждый момент времени и проверить, что вся прямая покрыта в каждый момент.

Для этого каждый прямоугольник (X1, Y1, X2, Y2) создаст 2 события "открылся отрезок с Y1 до Y2 во время X1" и "закрылся отрезок с Y1 до Y2 во время X2". Эти все события вы сортируете по X и в таком порядке обрабатываете.

Для отслеживания состояния прямой используйте дерево отрезков на минимум с отложенной суммой. Эта структура данных потребует массив на примерно 4n элементов для дерева с 2n листами. Каждая вершина будет хранить минимум на соответсвующем ей отрезке. При открытии прямоугольника вы должны добавить +1 на его отрезок. При закрытии - вычесть 1. Сначала открывайте прямоугольники, если время у событий одинаковое. Учитывайте это при сортировке. Так касающиеся по вертикали прямоугольники не создадут пустых мест.
Если после обработки какого-либо события вы получили минимум в дереве отрезков 0 и следующее событие имеет большую координату по X - то какая-то часть оказалась не покрыта. Еще есть случай, если первое событие не X1=левая граница покрываемого прямоугольника, или последнее событие - не X2=правая граница всего прямоугольника. Тут тоже покрытия нет.

Еще, аккуратно с целыми числами, чтобы если у вас 2 прямоугольника касаются горизонтальными сторонами - там пустое место не подсчиталось. Например, каждый лист дерева отвечает за единичный отрезок координат. Тогда изменяйте в дереве всегда отрезок от Y1 до Y2-1 для события с координатам Y1..Y2.

Можно так:

-- Создаём табличку
CREATE TABLE IF NOT EXISTS employee (id int PRIMARY KEY, name text not null, salary int not null);

-- Для примера две записи
insert into employee (id, name, salary) values (1, 'Иван', 10000);
insert into employee (id, name, salary) values (2, 'Пётр', 20000);

-- Обновляем запись
UPDATE employee set salary = 15000 WHERE id = 1;

-- Обновляем запись с нашим условием - если переданное значение больше того что уже хранится, то вставляем его, иначе оставляем как было
-- "переданное значение" тут =5000
UPDATE employee SET salary = max(salary, 5000) WHERE id = 1;

-- Ну и выбираем результат
SELECT * from employee;

В выводе будет:

1 Иван 15000
2 Пётр 20000

Ну и ещё есть выражение CASE и функция IIF(condition, on_true, on_false).