Akina

ALTER TABLE customer
ADD CONSTRAINT CHECK(phone REGEXP '^[0-9]{3}-[0-9]{2}-[0-9]{3}$');

https://dbfiddle.uk/?rdbms=mysql_8.0&fiddle=71012d...

Вы сравниваете тёплое с мягким.

Firewall - это программа или комплекс программ, выполняющая фильтрацию на основе правил. В т.ч. на основе ACL.
ACL - это правило либо блок данных для правила. В т.ч. это может быть и правило для Firewall.

В общем случае - нет.

Как я понимаю, мысль твоя бредёт вот в каком направлении: мы выполняем INSERT в основную таблицу, а триггер AFTER INSERT, имеющий доступ к сгенерированному значению автоинкрементного ключа именно свежесозданной записи, создаёт записи в связанных таблицах, используя именно это значение.

Так вот именно эта мысль - она некорректная. Причём по совершенно элементарной причине. Данные для вставки в связанных таблицах (не поля связи - других полей) триггер тоже должен откуда-то взять. А вот корректно передать их достаточно непросто. Их нельзя вставить в блок данных основной записи - там просто места для этого нет, сервер перед выполнением INSERT проверяет входные данные на соответствие количества значений количеству переданных данных, соответствие типов, непревышение размеров и пр. Значит, данные придётся передавать за пределами запроса. Да, тут есть варианты, типа определённых пользователем переменных, временных таблиц и протчая - но всё это ненадёжно, сложно и совершенно несопровождаемо. Следует ещё учесть то, что триггеры - это конструкция неотключаемая. Либо она выполняется при абсолютно любом INSERT, и тогда есть определённые проблемы (триггер, предназначенный для работы при INSERT .. VALUES с единственным блоком данных, вряд ли корректно обработает вставку нескольких блоков данных, INSERT .. SELECT или LOAD DATA), либо для выполнения запросов на массовое добавление триггер надо удалять и потом пересоздавать - а если это происходит в конкурентной среде?

В общем, триггер - неподходящая идея. Вот хранимая процедура (stored procedure) - это самое оно. Там можно реализовать логику ну практически любой сложности, с любыми обработками и проверками. Хотя и не следует забывать, что триггер выполняется наново для каждой отдельной вставляемой записи, так что его наличие, даже при достаточно простом и компактном коде, сильно скажется на скорости выполнения операций вставки, особенно вставки массовой.

при регистрации пользователя, я получаю lastInserdId() и добавляю статичные данные для этого пользователя в различные таблицы

Ненадёжно. Если между вставкой в основную таблицу и получением LAST_INSERT_ID() соединение будет разорвано и затем автоматически восстановлено, то полученное значение будет некорректным (вернее, получите NULL). А свежесозданная запись благополучно "повиснет в воздухе".
Чисто теоретически, базовая таблица пользователей обязана обеспечивать уникальность записи даже без учёта синтетического первичного ключа (например, поле логина явно должно быть уникальным). А коли так, и с учётом того, что все значения для свежевставленной записи нам известны, можно использовать INSERT INTO slave SELECT 'literal', main.id FROM main WHERE uniquecolumn = 'new value'.

PS. Не знаю, почему при обучении вставке данных все начинают с INSERT .. VALUES - как по мне, глубоко порочная практика. Сначала надо изучить и досконально освоить INSERT .. SELECT, и только потом упоминать про INSERT .. VALUES как более простой конструкции, применимой в частных случаях.

Допустим, существует некий алгоритм, который преобразует последовательность X длины M в последовательность Y, причём существует обратное преобразование. Неважно, что это за алгоритм конкретно - сжатие, создание "зерна" и пр. Но очевидно, что:

1. Количество вариантов последовательности X составляет K в степени M, где K - размер словаря, т.е. количество возможных различимых значений одного элемента последовательности X. В случае байтовой последовательности это байт, т.е. K=256.

2. Каждая последовательность X после преобразования даёт последовательность Y, причём две разные последовательности X дают разные последовательности Y.

Соответственно количество возможных последовательностей Y равно количеству возможных последовательностей X. И соответственно если существует хотя бы одна последовательность Y короче последовательности X, то существует хотя бы одна последовательность Y длиннее последовательности X.

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

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

Если отформатировать запрос, то он выглядит так:

SELECT * FROM `rsi` WHERE `tf`='4h'                         UNION 
SELECT * FROM `rsi` WHERE `tf`='15m'                        UNION 
SELECT * FROM `rsi` WHERE `tf`='4h'                         UNION 
SELECT * FROM `rsi` WHERE `situation`='perek' AND `tf`='1d' UNION 
SELECT * FROM `rsi`                                         UNION 

SELECT * FROM `levels` WHERE `situation`='support' AND `tf`='4h' UNION 
SELECT * FROM `levels` WHERE `tf`='1h' 

ORDER BY `time` DESC LIMIT 0,20

Сразу видно, что первые 4 подзапроса можно смело удалить.
А потом надо смотреть на структуру таблицы rsi, ибо именно из неё будут взяты имена полей объединённого набора записей. Судя по ошибке, там просто нет поля time.

Если текущая версия СУБД поддерживает оконные функции - то ROW_NUMBER() в CTE и отбор по rn=1 во внешнем запросе.

WITH cte AS (
    SELECT *, ROW_NUMBER() OVER (PARTITION BY list_name ORDER BY date DESC) rn
    FROM table
    )
SELECT *
FROM cte
WHERE rn = 1

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

SELECT t1.*
FROM table t1
NATURAL JOIN (
    SELECT list_name, MAX(date) date
    FROM table
    GROUP BY 1
    )

Оба запроса предполагают уникальность (list_name, date).

Сталкивались. Причём именно с T520.

Оказалось, проблема в прошивке (точнее, в самой флешке с прошивкой). Образ текущей прошивки сняли без проблем (кстати, рабочая прошивка и её копия - на флешке две копии прошивки, - частично не совпадают), найти типа рабочую прошивку в Инете - тоже без проблем... Но найти комбинацию прошивки и новой флешки, которая бы заработала нормально, нам не удалось (впрочем, врать не буду - не сильно упирались, перепробовали с десяток имевшихся под рукой флешек и угомонились), а стоимость ремонта у фирмачей оказалась неоправданно дорогая (да ещё и "везите к нам, будем смотреть"). Сейчас уже где-то с год работает подключенным к аппаратному сетевому принт-серверу (трёхпортовый старенький D-Link) по USB - по цене решения не сравнить.

Если связь между значениями - статическая, жёсткая и никогда не изменяемая, то используйте вычисляемое поле (generated column). Если значение поля, от которого зависит другое поле - числовое от единицы и далее, можно обойтись одним полем типа ENUM.

Если же связь более сложная и/или может меняться со временем, то гораздо разумнее не заполнять второе поле в зависимости от первого, а использовать его значение как ссылку (foreign key) в словарную таблицу.

Крайний случай - использование BEFORE INSERT/UPDATE триггеров.

andry33822, огорчу. Описанная мной в комментарии к вопросу процедура требует ВСТАВКИ записи в таблицу users и ОБНОВЛЕНИЯ существующей записи в таблице users_apikey. То есть INSERT в одну таблицу + UPDATE другой таблицы.

В один запрос это никаким образом не укладывается. Но задачу можно решить. Триггером.

CREATE TRIGGER tr_assign_apikey_to_user
AFTER INSERT 
ON users
FOR EACH ROW
UPDATE users_apikey SET username = NEW.username WHERE username = '' LIMIT 1;

DEMO fiddle

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