SQL и Анализ данных
Базы данных и всё, что с ними связано! Сотрудничество: @haarrp РКН № 6766085482
نمایش بیشتر📈 تحلیل کانال تلگرام SQL и Анализ данных
کانال SQL и Анализ данных (@databases_tg) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 12 444 مشترک است و جایگاه 9 770 را در دسته فناوری و برنامهها و رتبه 51 458 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 12 444 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 05 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر -82 و در ۲۴ ساعت گذشته برابر -3 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 12.49% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 5.99% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 1 554 بازدید دریافت میکند. در اولین روز معمولاً 746 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 5 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند sql, индекс, user_id, строка, субд تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Базы данных и всё, что с ними связано!
Сотрудничество: @haarrp
РКН № 6766085482”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 06 اکتبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
UPDATE products SET price = 50500 WHERE id = 1;Этот запрос меняет значение price только у записи с id = 1. С помощью UPDATE можно изменить сразу несколько полей:
UPDATE products SET price = 78500, quantity = 3 WHERE id = 2;Этот запрос обновляет параметры price и quantity у записи с id = 2. 💡 UPDATE используют, когда нужно: ➖ изменить значение в конкретной записи, ➖ обновить несколько полей за один запрос, ➖ выбрать строки по условию, ➖ массово изменить набор записей. 🔗 SQL — это база для работы с базами. Если хотите не просто понять одну команду, а уверенно собирать запросы и менять данные без ошибок, регистрируйтесь на бесплатный мини-курс «MySQL для новичков» от Академии Selectel ➡️ Программа состоит из коротких уроков, которые помогут пройти путь от установки и настройки СУБД до создания таблиц, управления пользователями и основных операций с данными. Реклама. АО "Селектел". erid:2W5zFHzH7Eh
CREATE TABLE transactions (
id int PRIMARY KEY,
user_id int,
ts timestamp,
amount int
);
Нужно найти пользователей, у которых баланс ни разу не становился отрицательным.
Начальный баланс — 0.
Но есть важное условие:
все операции с одинаковым ts происходят одновременно, поэтому порядок строк внутри одного timestamp учитывать нельзя.
Пример:
10:00 +100 11:00 -80 11:00 -30 11:00 +20 12:00 +50В 11:00 изменение баланса должно считаться как:
-80 - 30 + 20 = -90То есть баланс:
10:00 → 100 11:00 → 10 12:00 → 60Наивный вариант:
SUM(amount) OVER (
PARTITION BY user_id
ORDER BY ts
)
может дать неправильную логику, если считать операции с одинаковым ts по отдельности.
Задача: написать SQL-запрос, который сначала объединит операции одного пользователя с одинаковым timestamp, а затем проверит минимальный накопительный баланс.
CREATE TABLE payments (
id int,
amount int
);
INSERT INTO payments VALUES
(1, 100),
(2, 100),
(3, 200);
SELECT
id,
amount,
SUM(amount) OVER (ORDER BY amount) AS total
FROM payments
ORDER BY id;
Многие ожидают:
1 | 100 | 100
2 | 100 | 200
3 | 200 | 400
Но результат будет другим:
1 | 100 | 200
2 | 100 | 200
3 | 200 | 400
По умолчанию PostgreSQL использует окно RANGE ... CURRENT ROW. Строки с одинаковым amount считаются равными соседями и попадают в окно вместе.
Для построчного накопления нужно указать ROWS:
SUM(amount) OVER (
ORDER BY amount, id
ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW
)
#SQL #PostgreSQL #DatabaseSELECT, а потом уменьшить его отдельным запросом, два покупателя могут одновременно увидеть последнюю единицу.
В PostgreSQL проверку и списание можно объединить:
UPDATE products
SET stock = stock - 1
WHERE id = 42
AND stock > 0
RETURNING id, stock;
Что получится при одновременных запросах:
• Первый покупатель уменьшит остаток с 1 до 0.
• Второй дождётся освобождения строки, и условие stock > 0 будет проверено повторно.
• Его запрос не обновит строку и ничего не вернёт — товар закончился.
Так работает обычный уровень изоляции PostgreSQL READ COMMITTED.
Добавьте защиту от отрицательных остатков:
ALTER TABLE products
ADD CONSTRAINT stock_nonnegative
CHECK (stock >= 0);
Списание остатка и создание заказа выполняйте в одной транзакции, чтобы при ошибке заказа изменение остатка тоже откатилось.