fix some mistakes
This commit is contained in:
@@ -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 нет ни одного заказа, сколько строк вернёт твой запрос и почему?
|
||||
|
||||
|
||||
Reference in New Issue
Block a user