homework/mnoskov/Теория БД/1. Ускорение и масштабирование/1. Индексы/practice_indexes.sql

/*Задание 1: По каким полям делать индексы(тут говорится смотреть на таблицы из пет проекта 'Онлайн магазины', надеюсь смотреть на таблицы а не на витрины):
    1) По каким полям, как тебе кажется, реальный продукт‑менеджер или аналитик будет чаще всего:
        where:
            users: age, email, registration_date,
            enrollments: enrolled_at
            courses: title, category
            lessons:  title, duration_min
            lesson_views: viewed_at
        order by:
            users: id, age, registration_date
            enrollments: user_id, enrolled_at
            courses: id
            lessons:  id, duration_min
            lesson_views: user_id, viewed_at
        group by:
            users: age, registration_date
            enrollments: user_id, course_id, enrolled_at
            courses: category
            lessons:  course_id
            lesson_views: user_id, lesson_id
        join:
            users: id
            enrollments: user_id, course_id
            courses: id
            lessons:  id, course_id
            lesson_views: user_id, lesson_id
    2) Для каждого поля, которое ты назвал, укажи: «индекс нужен / индекс не нужен» и коротко объясни почему (часто фильтруем, редко фильтруем, мало разных значений и т.п.).
        users: 
            id(есть автоматически),
            age(не нужен, мало разнах значений),
            email(нужен, чтобы найти пользователя через where)
            registration_date(нужен, часто будет сравниваться в BETWEEN наприме, и сортироваться)
        enrollments:
            user_id(нужен, будет часто джоиниться),
            course_id(нужен, будет часто джоиниться),
            enrolled_at(нужен, часто будет сравниваться в BETWEEN например, и сортироваться)
        courses:
            id(есть автоматически),
            title(не нужен, мало разных значений),
            category(не нужен, мало разных значений)
        lessons:
            id(есть автоматически),
            course_id(нужен, будет часто джоиниться),
            title(не нужен, мало разных значений),
            duration_min(мне кажется не нужен, тк не очень часто будет использоваться)
        lesson_views:
            user_id(нужен, будет часто джоиниться),
            lesson_id(нужен, будет часто джоиниться)
            viewed_at(нужен, часто будет сравниваться в BETWEEN например, и сортироваться)*/

-- Задание 2: Свяжи запрос и индекс:
    -- 1)
        SELECT * FROM users WHERE email = 'какой-то email'; -- индекс на email ускорит where
    -- 2)
        SELECT * FROM users WHERE is_active = true AND created_at >= CURRENT_DATE - INTERVAL '1 year'; -- индекс на created_at ускоряет where
	-- 3)
		SELECT * FROM products WHERE category = 'Электроника' ORDER BY  price; -- индекс по price ускорит order by
	-- 4)
		SELECT * FROM orders WHERE user_id = 1 AND order_date >= CURRENT_DATE - INTERVAL '30 days'; -- индекс на user_id и order_date ускорят where
	-- 5)
		SELECT order_id, product_id FROM order_items; -- на у тут по идее составной создается сразу, так как тут pkey составной. Ну и они ускоряют select

/* Задание 3. Порядок столбцов в индексе
	 1) Я бы сделал orders(order_date, user_id).
	 2) Для первых двух будет работать четко, а для третьего хуже. Тк у третьего нет фильрации по order date, и он стоит вторым в индексе
	 3) 
	 	* Когда один индекс - хорошо с фильтрацией по нескольким полям, и когда первое поле указанное в индексе используется часто, а второе нет.
	 	* Когда индекса два - хорошо когда оба поля фильтруются по отдельности*/

/* Задание 4. Лишние индексы в наших таблицах
	!!! Я тут не буду писать индексы которые создаются автоматически из за pkey
	users:
		Скорее нужен индекс:
			email, created_at(нужны для where, и order by)
		Скорее не нужен индекс:
			name, age, country, is_active(либо мало рахных значений, либо не очень востребованы эти поля)
	products:
		Скорее нужен индекс:
			price (для order by и where)
		Скорее не нужен индекс:
			name, ctegory, in_stock(либо мало разных значений, либо не очень востребованы эти поля)
	orders:
		Скорее нужен индекс:
			user_id(для join), price(для order by и where)
		Скорее не нужен индекс:
			name, category, in_stock(либо мало разных значений, либо не очень востребованы эти поля)
	order_items:
		Скорее нужен индекс:
			price_at_purchase (для order by и where)
		Скорее не нужен индекс:
			quantity(мало разных значения)
	
	Много индексов не есть хорошо, потому что они тоже занимают помять и их тоже нужно считать. Если их бездумно везде понатыкать то запрос может выполняться дольше.*/

/* Задание 5. Что должно быть уникальным
	1) id, email
	2) id, article_number(придумал вот такое)
	3)
		* Если не будет уникаьности по id, то возникнут проблемы бд, что у разных пользователей будет один id и это жопа, ничего невозможно фильтровать и тд.
		* Если email будет повторяться, то как вообще пользователи будут входить в аккаунт, и как делать персонализированную рассылку? Никак.
		* Если article_number будет повторяться, то те же проблемы что и с id, будет нарушение логики работы бд.
		
		* Уникальный индекс обезопасит бд от сбоев и некорректной работы.*/

-- Задание 6. Где индексы помогут, а где нет
	SELECT * FROM users WHERE id = 100; -- индекс уже создан тк это pkey
	SELECT * FROM users WHERE email = 'user@example.com'; -- нужен, поможет с where, быстрее будет рабоать фильтрация
	SELECT * FROM products WHERE price BETWEEN 100 AND 500; -- нужн, поможет с where, быстрее будте фильтрация
	SELECT * FROM products WHERE name LIKE '%phone%'; -- не нужен, индекс не рвботает с like
	SELECT * FROM orders WHERE status = 'DELIVERED'; -- не нужен, в status мало разных значений
	SELECT * FROM order_items WHERE order_id = 123; -- нужен, поможет с where, быстрее будет рабоать фильтрация