Akina

Запомните одну вещь. Многие её забывают или не знают, и из этого проистекают все их проблемы.

Внешний ключ (FOREIGN KEY) - это ПРАВИЛО. Всё остальное - либо дополнения, либо следствия. Народ начинает рассказывать про индексы и прочее - НЕТ! Не включайте всё это в определение собственно внешнего ключа.

Хотя оно хранится в структуре таблицы, оно является не частью структуры таблицы, а инструкцией, которая будет обрабатываться подсистемой контроля целостности и непротиворечивости данных - есть такая в составе SQL-сервера.

Это правило устанавливает, что при добавлении/изменении значения следует проверить существование нового значения в ссылочной таблице. И наоборот - при удалении следует проверить отсутствие удаляемого значения в ссылающейся таблице. То есть правило работает в обе стороны - влияет не только на таблицу, в которой оно определено, но и на упомянутую в правиле таблицу, при этом в структуре ссылочной таблицы никакого упоминания о существовании этого правила нет. Но, поскольку подсистема контроля - это подсистема уровня сервера, то ей плевать, где прописано.

Это правило может быть дополнено опциями каскадной операции ON DELETE/UPDATE - в этом случае после контроля нового значения подсистема даёт дополнительную команду на выполнение указанных в опции изменений зависящих данных.

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

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

create table test(
  id SERIAL PRIMARY KEY,
  num int,
  t text,
  constraint u_constrainte unique (num, t) DEFERRABLE 
)

https://dbfiddle.uk/VuwdSZSH

Можно ли как то сделать сортировку того что нужно обновить перед тем как собственно обновлять записи?

Нет.

Для поиска двойной кавычки используется строковый литерал из четырёх двойных кавычек
Instr(start, variable, """")
Первая и последняя обрамляют литерал, вторая и третья образуют удвоенную двойную кавычку, которая интерпретируется как квотированная/экранированная.

Есть и более простой способ.
Instr(start, variable, Chr(34))

-=о=--=о=--=о=--=о=--=о=--=о=--=о=-

У меня в ячейки есть текст:
ДООП "Лабаратория Хлеба" естественно-научной направленности

Надо что бы она в соседнюю ячейку написал:
ДООП "Лабаратория Хлеба"

Если ты точно знаешь, что значение содержит не менее 2 двойных кавычек, и нужно отделить именно до второй включительно, можно так:

Function get2dquotes(source As String) As String
    Dim tmp() As String
    tmp = Split(source, Chr(34))
    get2dquotes = tmp(0) & Chr(34) & tmp(1) & Chr(34)
End Function

И соответственно потом B1=get2dquotes(A1).

Глобально: никакие.

Уровня БД либо отдельных объектов БД: данные - всё, кроме FILE; структура - CREATE TEMPORARY TABLES и (если используются хранимые объекты) EXECUTE.

Ну а далее - плюс дополнительные необходимые права, в зависимости от кривизны структуры и работы с базой.

DELIMITER - это не SQL-запрос, а команда клиента. PyMySQL - это не клиентская программа, а библиотека доступа, которая ни про какой DELIMITER не знает и знать не должна. Отсюда и ошибка. Опять же - нет никакого смысла напихивать в код лишнюю логику, без которой можно спокойно обойтись.

А если от всей лишней шелухи избавиться, то от всей логики останется один-единственный оператор. Который сделает использование DELIMITER и вовсе ненужным.

CREATE TRIGGER setUUID 
BEFORE INSERT ON users
FOR EACH ROW 
	SET NEW.uuid = COALESCE(NEW.uuid, UUID());

SELECT 
  *,
  FIRST_VALUE(CASE WHEN banner_id IN (13,14,15,17)
                   THEN banner_id 
                   END) OVER (PARTITION BY id
                              ORDER BY CASE WHEN banner_id IN (13,14,15,17)
                                            THEN banner_id 
                                            END DESC NULLS LAST) max_banner_id_1,
  FIRST_VALUE(CASE WHEN banner_id IN (4,177,178)
                   THEN banner_id 
                   END) OVER (PARTITION BY id
                              ORDER BY CASE WHEN banner_id IN (4,177,178)
                                            THEN banner_id
                                            END DESC NULLS LAST) max_banner_id_2
FROM test
ORDER BY banner_id

PRIMARY KEY - первичный ключ. Поле, комбинация полей либо выражение (последнее MySQL не поддерживает), которое не может быть NULL и не допускает дубликатов (уникально для каждой отдельной записи в пределах таблицы). Поддерживается путём создания соответствующего уникального индекса и наложением ограничения NOT NULL на все используемые в выражении поля. По факту - однозначно идентифицирует запись. Кроме того, в MySQL выражение первичного ключа является кластерным индексом. См. Индекс -> Уникальный индекс -> Первичный индекс.

CONSTRAINT - ограничение. Правило, которое не допускает создания записи, для которой значение выражения ограничения имеет значения FALSE (можно TRUE или NULL).

FOREIGN KEY - внешний ключ. Ограничение, которое требует, чтобы указанное выражение для текущей записи присутствовало среди значений указанного выражения референсной таблицы (допускается и внешний ключ на ту же таблицу). Точнее, чтобы такая проверка присутствия не возвращала FALSE (можно TRUE или NULL).

REFERENCES - определяет референсную таблицу и референсное выражение.

INSERT INTO - запрос, вставляющий новые записи в таблицу.