4 changed files with 20 additions and 20 deletions
@@ -1,4 +1,4 @@
-CREATE TABLE users (
+CREATE TABLE dmezentsev.users (
 id BIGINT PRIMARY KEY, /* сделал первичные ключи в каждой таблице BIGINT, кол-во
 записей может быть большим */
 name VARCHAR(100) NOT NULL,
@@ -9,7 +9,7 @@ is_active BOOLEAN,
 created_at TIMESTAMPTZ NOT NULL
 );

-CREATE TABLE products (
+CREATE TABLE dmezentsev.products (
 id BIGINT PRIMARY KEY,
 name VARCHAR(100) NOT NULL,
 category VARCHAR(50),
@@ -17,7 +17,7 @@ price DECIMAL(10,2) NOT NULL, -- Сделал тип данных для ден
 in_stock BOOLEAN
 );

-CREATE TABLE orders (
+CREATE TABLE dmezentsev.orders (
 id BIGINT PRIMARY KEY,
 user_id BIGINT NOT NULL,
 order_date TIMESTAMPTZ NOT NULL,
@@ -26,7 +26,7 @@ status VARCHAR(20), -- Читаемый статус нагляднее, не н
 FOREIGN KEY (user_id) REFERENCES users(id)
 );

-CREATE TABLE order_items (
+CREATE TABLE dmezentsev.order_items (
 order_id BIGINT,
 product_id BIGINT,
 quantity INT NOT NULL, /* Предположил, что типа данных SMALL INT возможно не
@@ -38,7 +38,7 @@ FOREIGN KEY (order_id) REFERENCES orders(id),
 FOREIGN KEY (product_id) REFERENCES products(id)
 );

-INSERT INTO users (id, name, age, email, country, is_active, created_at)
+INSERT INTO dmezentsev.users (id, name, age, email, country, is_active, created_at)
 VALUES 
    (1, 'Alice', 25, 'alice@example.com', 'US', TRUE, '2024-01-10 10:00:00'),
    (2, 'Bob', 30, 'bob@example.com', 'UK', TRUE, '2024-02-05 09:30:00'),
@@ -51,7 +51,7 @@ VALUES
    (9, 'Ivan', 26, 'ivan@example.com', 'RU', TRUE, '2024-01-11 14:30:00'),
    (10, 'Julia', 28, 'julia@example.com', 'US', TRUE, '2024-03-07 18:05:00');

-INSERT INTO products (id, name, category, price, in_stock)
+INSERT INTO dmezentsev.products (id, name, category, price, in_stock)
 VALUES 
    (1, 'iPhone 15', 'Электроника', 80000.00, TRUE),
    (2, 'Kindle', 'Электроника', 15000.00, TRUE),
@@ -61,7 +61,7 @@ VALUES
    (6, 'Фитнес-браслет', 'Гаджеты', 6000.00, TRUE),
    (7, 'Подарочная карта', 'Сервисы', 1000.00, TRUE);

-INSERT INTO orders (id, user_id, order_date, status)
+INSERT INTO dmezentsev.orders (id, user_id, order_date, status)
 VALUES 
    (1, 1, '2025-01-10 12:00:00', 'paid'),
    (2, 3, '2025-01-12 09:30:00', 'cancelled'),
@@ -72,7 +72,7 @@ VALUES
    (7, 7, '2025-03-01 09:00:00', 'paid'),
    (8, 9, '2025-03-05 19:30:00', 'paid');

-INSERT INTO order_items (order_id, product_id, quantity, price_at_purchase)
+INSERT INTO dmezentsev.order_items (order_id, product_id, quantity, price_at_purchase)
 VALUES 
    (1, 1, 1, 78000.00),
    (1, 3, 2, 8500.00),
@@ -6,7 +6,7 @@ SELECT name,
 		is_active
 FROM dmezentsev.users
 WHERE CURRENT_DATE - created_at::DATE > 180
-ORDER BY CURRENT_DATE - created_at::DATE DESC;
+ORDER BY days_since_registration DESC;

 /* - Как бы ты использовал такое поле в реальном продукте 
 (что можно делать с очень «старыми» пользователями)?
@@ -27,7 +27,7 @@ SELECT name,
 		SUBSTRING(LOWER(email) FROM POSITION('@' IN email) + 1) AS domain
 FROM dmezentsev.users		
 WHERE email IS NOT NULL 
-ORDER BY SUBSTRING(email FROM POSITION('@' IN email) + 1), name;
+ORDER BY domain, name;

 /* - Зачем в реальных системах приводят email к нижнему регистру и выделяют домен отдельно?

@@ -4,7 +4,7 @@ SELECT category,
 		count(id) AS products_count
 FROM dmezentsev.products
 GROUP BY category 
-ORDER BY count(id) DESC;
+ORDER BY products_count DESC;

 /* - Что будет, если убрать ORDER BY — как изменится чтение результата
 для продукта/аналитика?
@@ -26,7 +26,7 @@ SELECT order_id,
 		SUM(quantity * price_at_purchase) AS order_revenue
 FROM dmezentsev.order_items
 GROUP BY order_id
-ORDER BY SUM(quantity * price_at_purchase) DESC; 
+ORDER BY order_revenue DESC; 

 /* - Что будет, если убрать GROUP BY и оставить SUM(quantity * price_at_purchase)?

@@ -41,7 +41,7 @@ SELECT p.category,
 FROM dmezentsev.products p 
 JOIN dmezentsev.order_items oi ON p.id = oi.product_id
 GROUP BY p.category 
-ORDER BY SUM(oi.quantity * oi.price_at_purchase) DESC;
+ORDER BY category_revenue DESC;

 /* - Почему группировка идёт по p.category, а не по p.id?

@@ -62,7 +62,7 @@ FROM dmezentsev.orders o
 JOIN order_items oi ON o.id = oi.order_id
 WHERE o.status = 'paid'
 GROUP BY o.id
-ORDER BY SUM(oi.quantity * oi.price_at_purchase) DESC; 
+ORDER BY order_revenue DESC; 

 /* - Чем результат этой задачи будет отличаться от задачи 2 (где статус не учитывался)?

@@ -82,7 +82,7 @@ FROM dmezentsev.products p
 JOIN dmezentsev.order_items oi ON p.id = oi.product_id
 GROUP BY p.category 
 HAVING SUM(oi.quantity * oi.price_at_purchase) > 1000
-ORDER BY SUM(oi.quantity * oi.price_at_purchase) DESC;
+ORDER BY category_revenue DESC;

 /* - Почему нельзя написать WHERE category_revenue > 1000?

@@ -104,7 +104,7 @@ FROM dmezentsev.users
 WHERE is_active = TRUE
 GROUP BY country 
 HAVING COUNT(id) >= 2
-ORDER BY COUNT(id) DESC;
+ORDER BY active_users_count DESC;

 /* - Почему фильтр по активности (is_active = true) логичнее писать в WHERE, а не в HAVING?

@@ -124,7 +124,7 @@ SELECT name AS product_name,
 FROM dmezentsev.products p 
 JOIN dmezentsev.order_items oi ON p.id = oi.product_id
 GROUP BY name
-ORDER BY SUM(quantity) DESC
+ORDER BY total_quantity_sold DESC
 LIMIT 3;

 /* - Чем рейтинг по total_quantity_sold отличается от 
@@ -145,7 +145,7 @@ SELECT order_id,
 FROM dmezentsev.order_items
 GROUP BY order_id 
 HAVING SUM(quantity * price_at_purchase) < 100
-ORDER BY SUM(quantity * price_at_purchase);
+ORDER BY order_revenue;

 /* - Какие реальные причины могут быть у очень маленьких заказов (1–2 гипотезы)?

@@ -59,7 +59,7 @@ LEFT JOIN dmezentsev.products p ON oi.product_id = p.id AND oi.order_id = 101

 SELECT o.id AS order_id,
 		u.name AS user_name,
-		p.name,
+		p.name AS product_name,
 		oi.quantity,
 		oi.price_at_purchase
 FROM dmezentsev.orders o 
@@ -181,7 +181,7 @@ FROM dmezentsev.orders o
 JOIN dmezentsev.users u ON o.user_id = u.id
 JOIN dmezentsev.order_items oi ON o.id = oi.order_id
 JOIN dmezentsev.products p ON oi.product_id = p.id 
-WHERE u."name" = 'Alice';
+WHERE u.name = 'Alice';

 /* - Если у Alice нет ни одного заказа, сколько строк вернёт твой запрос и почему?