d-stream

Ничего не надо, просто переводим:

field_id = 805312 и field_value = 1417294800, и запись с field_id=805316 и field_value=2126254.

в
where
(field_id = 805312 and field_value = 1417294800)
or
(field_id=805316 и field_value=2126254)

Скобки лишь для акцентов

"в лоб" получаем записи, которые отстутсвуют в другой таблице и пихаем их в b

insert into b (.....)
select * from temp where temp.field not in (select distinct field from a)

Типа "оптимальнее"

insert into b (.....)
select * from temp
left join a on temp.field=a.field
where a.field is null

В принципе нормальный оптимизатор выполнит и первое и второе с одинаковой скоростью

Триггеры - фактически единственное, что обеспечит своего рода "целостность" задумки на уровне БД.

На уровне условного соглашения "не суваться к базе" мимо хранимых процедур - можно реализовать аналогичное на уровне ХП, но это не php-style -)

SQL придумали как почти естественный язык "попросить у базы":

select [выбрать]
* [все]
from Users [из Users]
where [когда/где/которые]
gender = Female and (today - birthday) < X [ женщины и возраст меньше х]
or (или)
gender = Male and (today - birthday) < X [мужчины и возраст меньше х]

Работает. Только моя телепатия подсказывает, что balans - строковый а пытаются хранить в нем цифры и потом возникает удивление почему 100,01 располагается не так рядом со 100,11

А что есть в рамках этого запроса joiners_artist.id ? Какой попало id из таблицы joiners_artist?

Как бы указана связка пары таблиц, а в условии вдруг возникает третья... Получается "к напильнику прикреплена ручка, сколько лет машинисту поезда?" -)

Видимо потерялся например вышестоящий select из joiners_artist - тогда все встанет на свои места. Или надо так или иначе присоединить таблицу joiners_artist

SET locality = (SELECT * FROM Localities WHERE Localities.Id = new.LocalityId);

Попытка присвоить переменной НЕСКОЛЬКИХ колонок

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

Предложение: не надо заниматься извратом.

Там в my.conf не надо случаем разрешить debug ?

1. Или сделать таблицы "истории" со структурой идентичной таблицам 1-3 + поле даты-времени или номера версии и при изменениях - перемещать туда изменяемые посты.

2. Ввести в таблицы признак "историчности" и при изменениях постов - добавлять их как новые, а у старых взводить флаг. Соответственно в отображении постов - фильтровать посты без флага

Выбор варианта зависит от возможности трогать исходные таблицы. Вариант 1 - может оказаться наиболее удобным, если хочется минимально вмешаться - достаточно просто поставить триггеры на update

А почему смущает (client1, client2) и (client2,client1) ?

К примеру если речь идет о доверенных лицах - то Вася может быть доверенным лицом Пети, а Петя может быть, а может и не быть доверенным у Васи.
Соответственно дальнейшие запросы "кому доверяет Вася" и "у кого в доверенных Вася" - отлично разруливаются, а "кто с кем имеет любые отношения" - разруливается с distinct

Может и полететь.
Например где-то в паре строк затесается не число
Или где-то это поле используется в строковых выражениях

А зачем шифрование и прочая? Зачем IP?

Хочется как-то идентифицировать анонимного пользователя при повторном заходе - генерим ему некий уникальный ID и скармливаем куку с ним.
В качестве уникального ID можно пользовать например автоинкрементное поле, но это если не страшит перебор "злобным хакером" соседние записи. Можно пользовать "стандартизированый" GUID/UUID

Достаточно быстро окажется, что надо как-то отслеживать поступление товаров, ремонт, списание и т.п.

В общем лучше сразу ориентироваться на документы поступления (откуда и считается кол-во всего), документы выдачи (сколько сейчас в прокате/аренде), документы возврата, документы выбытия и т.п.
Соответственно "набежит" по как минимум паре таблиц на каждую такую сущность (данные документа и строки документа).
Соответственно текущее состояние будет вычисляемым как сумма приходов минус суммы расходов, выдач, списаний), но в том числе будет доступна информация о движениях каждого элемента учета.

в рамках tsql подобное обычно реализуется либо логикой:

if exists(....) begin
вставка
end

либо insert from select, где в условии отбора селекта фигурирует в том или ином виде проверка наличия