/*Задание 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, быстрее будет рабоать фильтрация