SQLite на практике (курс от Антона Жиянова)

Мой коллега Антон Жиянов сделал курс по практическому применению sql в работе, очень рекомендую — https://antonz.ru/sqlite-course/.

Курс бессрочный, оплатил и делаешь хоть полгода! Ну тут кому как, кого-то мотивирует куча времени, кого-то расхолаживает )))) 

Антон отлично пишет, это можно проверить по его блогу. Прекрасные статьи, написанные просто и понятно! А еще Антон хорошо объясняет, далекие 6 лет назад именно он обучал меня на проекте )))

Так что лично я вписалась, чего и вам советую. Практики много не бывает! 

Найти объединенные данные (мое решение)

На прошлой неделе публиковала задачку по SQL, которая попалась мне на работе — «Найти объединенные данные». Хочу рассказать, как я ее решала.

Перед тем, как строить догадки, я посмотрела на парочку идентификаторов «вживую» и сделала вывод, что часть из них окажется неактуальными. Тогда мне казалось, что все, что от меня надо — доказать свою теорию числами. Пффф!

Но это не такая простая задачка, как оказалось. Сначала я пошла втупую — скопировала первую колонку и попробовала сделать запрос in (1, 2, 3...). Выяснилось, что внутри IN может быть только 1000 параметров, а у меня их 82 000. Облом-с.

Но ведь можно работать с таблицей! То есть главное — запихать наши 82 000 в некую темповую табличку с данными. Тут следующий облом — я умею через Workhbench, а на сервере его нету. Пошла гуглить, как без него, нашла только load data, расстроилась. Уже думала попросить админов мне файлик на сервер закинуть, как коллега услышал про мои страдания и показал, как загружать файлы через sql developer (см пункт 2).

Итак, ура, данные загрузили! Что дальше?

Подготовка тестовых данных

А что, вы думали, что я сразу понесусь тестировать на миллионах данных? Нет, конечно, сначала скрипты надо обкатать на небольшом объеме. А то так запустишь селект, который 2 часа работает, а потом поймешь, что результат невалидный, так как ты про is not null забыл, или другое условие.

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

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

ID_PARTY	GROUPING	Комментарий
3048	1	Уже объединены. Исходный 3048. Его ИД больше ИД золотого
3041	1
5162	2	Уже объединены. Исходный 5155. Его ИД меньше ИД золотого
5155	2
...	...	...

Вот что получилось у меня:

Задачка по SQL. Найти объединенные данные

У нас можно объединять несколько карточек в одну. Вот, например, были карточки id = 1 и id = 2, которые потом объединились в id = 11.

Как это выглядит в базе данных:

1. В таблице самих карточек есть колонка Merged_status, принимает значения:

• 0 — не объединялась никогда и не результат объединения;
• 1 — объединена (id = 1 и id = 2)
• 2 — результат объединения (id = 11)

id_party	Merged_status
1	1
2	1
11	2

2. Есть отдельная табличка MERGED, в которой указано, кто, в кого и когда был объединен.

• id_party — идентификатор исходной записи, которая была объединена;
• id_final — идентификатор результата объединения;
• created — дата объединения;
• cancelled — дата разъединения (не будем вникать в технические детали, просто такое может быть и тогда она будет непустой).

Для нашего случая:

id_party	id_final	created	cancelled
1	11	15.06.2017
2	11	15.06.2017

Задачка

Где-то в другой системе решили сопоставить свои идентификаторы и наши. Нашли случаи, когда клиент вроде как один в системах A, B, C, но у нас он не объединен. Выгрузили, получился csv файлик такого содержания