mayton2019

Сам себе отвечаю.

collect_list() и explode()

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

Но практически - моя постановка изменилась и сейчас сводится к работе с JSON-arrays которые лежат
в ячейках таблицы. Для них collect/explode мне не подошел. А подошли функции transform и cast.
Часть из них доступны начиная со Spark 3.1.1 и Databricks 9.1.x-LTS Runtime. Поэтому надо модернизироваться срочно.

Обычно там где танцует Go - там рядышком docker/kubernetes. Тоесть не проблема очень быстро поднять тестовую БД, наполнить ее данными и сразу прогнать все тесты по DAO.

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

Изучать SQL как сферический язык в вакууме - нет особого смысла. Особенно если ты спрашиваешь про хинты. Хинты - это опция конкретной реализации DBMS. У Оракла - свои хинты. У Microsoft - свои. И знания между ними - совершенно не переносимые. И сами хинты кажется не стандартизированы в SQL стандарте. Здесь я могу ошибаться - пускай знающие подскажут.

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

Я в своё время тоже искал теоретическую литературу по оптимизации SQL. Нет толком ничего. Есть Ден Тоу. Настройка SQL для профессионалов. Он пытается подогнать под оптимизацию свою теорию. Считает селективности и кардинальности для суб-запросов и рисует "облачки" - диаграммы пытаясь вывести формулу cost. Но это всё не работает. Это разбивается о практику. Ни одна практика Oracle/PG/MSQL/MySQL не подрверждает эффеткивности диаграмм Тоу. Вобщем я зря потратил время на чтение этой книги. И тебе не советую.

Бери конкретные книги от вендора и по ним смотри.

И в твоём вопросе не хватает еще одного хеш-тега.

Что за вертикальная палочка? Зачем она?

ALTER TABLE sl.lesson {
    DROP CONSTRAINT lesson_timetable_id_fkey |
    DROP COLUMN timetable_id
}

А это что?

liquibase.exception.ValidationFailedException: Validation Failed:

Изменял change-sets грязными руками? Этого нельзя делать. То что установлено в репо - маркируется контрольной суммой и нельзя фиксить задним числом. Создаёшь новый changeset который исправляет.

Вам определенно нужен девопс который автоматизирует вам выполнение ваших скриптов по календарю. Добавит дашборды с графиками и прочее.

DataGrip насколько я понимаю это среда разработки. Тоесть она активна пока у вас крышка ноутбука отрыта. Закрыли - всё. Капец все планам.

Поэтому девопс и еще раз девопс.

У Оракла есть короткий синтаксис внутренних соединений. Вообще JOIN не нужно указывать.

SELECT 
  t1.ID, t1.TIME
FROM 
  t1,t2 
WHERE t1.ID = t2.ID
  AND trunc(t1.TIME, 'hh24') = trunc(t2.TIME, 'hh24')

И есть общая рекомендация - выделять ключевые слова SQL в uppercase. Так их удобнее видеть.

SELECT 
 `user_id`, `username`, `first_name`,`last_name`, `title` 
FROM 
 `userdata` 
WHERE 
 `type` LIKE '%group'

Не приживаются они для СУБД.

IDE-шки. Вот такие дела. Редко когда тебе нужно открывать в Oracle PLSQL Developer десяток PLSQL пакетов.

Так вообще вместо IDE используют IDE основного языка программирования. В нем и пишут текст. Тем более что 99% он инкапсулирован в ORM.

Попробуй на сайте JetBrains скачать что-то. И еще DBeaver был. Там удобно каталоги баз вести.

Можно использовать inline views (или еще называют common table expressions)

with cp_view as (
 select cp.chat_id
 from chat_participants cp
 where cp.user_id = 1 and cp.is_deleted = false)
.....

Нужно помнить о том что между вычитыванием 1-й и 2-й страницы таблица могла быть изменена. И процесс может либо пропустить какую-то строку либо прочитать дубликат. У этой проблемы есть много решений. Почти все они лежат в плоскости транзакций. Но поскольку тема тегирована только SQL - то непонятно с какой dbms мы имеем дело. Реализация режимов транзакций - вещь крайне нестандартизированная.

Тоесть чтобы обсуждать правильный pagination нам нужно понять что по ту сторону application. Oracle? MSSQL? e.t.c.

Если ты разбиваешь 1 запрос на 3 мелких - то тебе нужно оборачивать их транзакцией или доказывать что между запросами не будет посторонних модификаций данных. Иначе 3 запроса не будут эквивалентны первому. Это кстати типичная джуниорская ошибка - неучет ACID.

Тут надо сначала смысл разобрать. Вот как ты себе понимаешь что магазин открылся в 22.00 а закрылся в 5.00 ?
Закрылся в 5.00 утра следующего дня? Работал всего 7 часов. Это один кейс. А другой кейс - если свапнуть время - то получается что работал 15 часов. Выводы? Свапать нельзя никак.

А вот когда смысл проверки мы поймем - тогда можно и код писать. В крайнем случае - хранимую функцию написать.