Akina

SELECT * 
FROM test
ORDER BY CASE status WHEN 'cancelled'
                     THEN 1
                     ELSE 2
                     END;

https://dbfiddle.uk/?rdbms=oracle_11.2&fiddle=30ad...

SELECT b.`id`, b.`date`, l.`path` 
FROM `buy` b
INNER JOIN `em` e ON b.`em_id` = e.`id`
INNER JOIN `ls` l ON FIND_IN_SET(l.`id`, b.`ls_id`)

PS. Хранение данных в CSV - это денормализация, дурной тон, и вообще кривой переулок, ведущий прямо на поле с граблями...

SELECT ft.*, pt.*
FROM fruit_table ft
JOIN param_table pt ON ft.id=pt.id_fruit
JOIN ( SELECT id_fruit
       FROM param_table
       WHERE id_param IN (10, 20)
       GROUP BY 1
       HAVING COUNT(DISTINCT id_param) = 2 ) ptx ON pt.id_param = ptx.id_param

Нужно получать курс первого дня, для выбранного периода - first, и последнего дня - last. Чтобы высчитать разницу. После чего {last} - {first} = {Х}. И вот по этому {Х} делать сортировку выборки.

Да запрос же тривиальный!

SELECT DISTINCT 
       coin_uuid,
       FIRST_VALUE(price) OVER (PARTITION BY coin_uuid ORDER BY last_updated ASC) firstprice,
       FIRST_VALUE(price) OVER (PARTITION BY coin_uuid ORDER BY last_updated DESC) lastprice
FROM exchange_rates
ORDER BY coin_uuid, lastprice - firstprice

Слишком абстрактный вопрос. И ответ такой же - возможно, имеет.

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

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

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

Проверьте свойства (подключения, профиля) - возможно, именно это имя БД указано как база по умолчанию. И добрый Workbench, чтобы не плеваться ошибками на несуществующую БД, просто создаёт её. Или БД по умолчанию вообще не указана, и Workbench вытаскивает это имя откуда-то из своего загашника с дефолтными значениями.

таблицы стали создаваться именно в ней, а не в той схеме с которой я работаю

Если при создании таблицы указано её имя с указанием имени БД (CREATE TABLE dbname.tablename ( .. );) - таблица будет создана именно в указанной БД. Если же имя БД не указать - таблица создаётся в текущей БД. Почему у Вас именно эта БД текущая, и почему Вы не меняете её перед созданием таблиц запросом USE - это именно к Вам вопросы, и именно Ваша вина в том, что таблицы создаются "не там".

Пример реализации для MySQL 8+:

WITH 
cte1 AS ( SELECT id, col1 val FROM test UNION ALL 
          SELECT id, col2 FROM test UNION ALL
          SELECT id, col3 FROM test ),
cte2 AS ( SELECT id, GROUP_CONCAT(val ORDER BY val) FIO
          FROM cte1 
          GROUP BY id )

SELECT test.id, test.col1, test.col2, test.col3, GROUP_CONCAT(cte2_2.id) ids
FROM test
JOIN cte2 cte2_1 USING (id)
JOIN cte2 cte2_2 USING (FIO)
GROUP BY test.id, test.col1, test.col2, test.col3

Вывод:

id	col1		col2		col3		ids
1	Иванов		Иван		Иванович	1,2
2	Иван		Иванович	Иванов		1,2
3	Петров		Сергей		Алексеевич	3,4,5
4	Петров		Сергей		Алексеевич	3,4,5
5	Сергей		Алексеевич	Петров		3,4,5

DEMO

Если нужна ещё и нормализация (т.е. строго в col1 сунуть фамилию, в col2 имя...) - наилучшим вариантом считаю загрузку справочников имён, отчеств и фамилий (вполне доступные справочники) и их использование для категорирования. 99% записей будут полностью обработаны по ним, а оставшийся десяток записей (где два или все три значения отсутствуют в справочниках) можно и вручную обработать, вернее, пополнить справочник, чтобы при втором запуске все 100% были распознаны и категорированы корректно.

выполняться будет на MS SQL Server, версию не могу сказать.

Для MS SQL вместо GROUP_CONCAT будет STRING_AGG(column) [WITHIN GROUP ( ORDER BY column)]. https://docs.microsoft.com/ru-ru/sql/t-sql/functio...

что эффективнее: хранить в записи список id объектов, которые должны быть обработаны при обращении к этой записи, в виде строки (скрипт будет парсить строку и отрабатывать каждый id), либо сделать триггер и хранимую процедуру (MySQL), которая возьмёт эту работу на себя?

Ни то ни другое.

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

Но есть ещё косяк - в том, как хранятся данные. Упаковка набора данных в одну запись в виде CSV-списка - это тоже дурь в подавляющем большинстве случаев. Умные люди не зря придумали нормальные формы, которые позволяют обрабатывать данные максимально эффективным образом.

Вот и займитесь - почитайте про нормализацию, нормализуйте схему БД. А потом обрабатывайте данные на сервере как надо. В большинстве случаев оказывается, что супер-пупер-сложная обработка сводится на самом деле к одному не сильно сложному запросу.

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