Знаете ли вы, что в PostgreSQL можно создавать свои собственные программки прямо внутри СУБД?

В PostgreSQL есть много встроенных функций, задача которых облегчать нам жизнь.

Например:

- round(3.14159, 2) возвращает 3.14
- length('PostgreSQL') возвращает 10
- now() возвращает текущую дату и время

Почти любая операция уже готова к использованию.

А что, если вам нужно каждый день считать некоторый финансовый показатель магазина, например — цена × количество × (1 - скидка) × (1 + НДС) с округлением, то писать это заново утомительно, а готового решения вероятно не будет.

Создайте свою программу, то есть функцию прямо на SQL:

CREATE OR REPLACE FUNCTION calc_revenue(price NUMERIC, qty INTEGER, discount NUMERIC DEFAULT 0)
RETURNS NUMERIC AS
$$
SELECT round(price * qty * (1 - discount) * 1.20, 2);
$$ LANGUAGE SQL;

Теперь просто вызываете функцию, указывая там свои параметры:

SELECT calc_revenue(1000, 5, 0.1); — 5400.00

Код чище, ошибок меньше, удобно переиспользовать.

📊 Данные как зеркало бизнеса: что они говорят о компании ?

У каждого бизнеса есть своё зеркало.
Нет, не то, в котором отражается офис или логотип.
А то, в котором отражается его настоящее состояние — сильные стороны, слабые места, ошибки, победы и возможности.
И этим зеркалом являются данные.

🔍 1. Данные показывают не то, что бизнес хочет видеть, а то, что есть на самом деле.

Можно бесконечно обсуждать стратегию, спорить о гипотезах и строить красивые презентации.
Но когда мы открываем данные — всё становится проще и честнее.

В цифрах нет эмоций.
Нет оправданий.
Нет «нам казалось».

Есть только факты.
И это делает данные самым честным источником истины в компании.

🧭 2. Данные показывают направление развития.

Посмотрите на метрики — и вы увидите динамику:
куда бизнес движется, что растёт, что проседает, какие изменения приносят пользу, а какие — только создают иллюзию движения.

Данные — это навигатор.
Без него можно долго ехать красиво, но в неверную сторону.

🫥 3. Данные подсвечивают проблемы, которые иначе останутся в тени.

Часто компания узнаёт о проблеме только тогда, когда она становится слишком большой.

Но данные умеют предупреждать заранее:

- падает активность пользователей;
- уменьшается конверсия;
- растут издержки;
- клиенты уходят чуть быстрее, чем приходят.

Если смотреть в зеркало регулярно — можно заметить трещины, пока они ещё маленькие.

📈 4. Данные показывают зрелость компании

У зрелых компаний есть культура измерений.
Они знают свои ключевые метрики, отслеживают изменения, строят прогнозы и принимают решения осознанно.

У незрелых — хаос.
Данные либо отсутствуют, либо не доверяют тем, что есть, либо смотрят на них только тогда, когда «припекло».

Зрелость бизнеса начинается там, где начинается зрелость работы с данными.

💬 5. Что главное?

Данные — это не просто отчёты.
Это не цифры ради цифр.
Это голос бизнеса.

Если прислушаться, данные говорят:

- где вы сильны,
- где ошибаетесь,
- куда стоит идти,
- а куда — точно не стоит.

И задача аналитиков — не просто собрать эти данные, а помочь компании услышать себя.

🏁 Итог

Данные — это отражение бизнеса.
Аналитика — способ увидеть это отражение ясно.
И те, кто умеют с этим работать, дают компании шанс расти осознанно, а не вслепую.

Всем привет.
Разберем прошлый вопрос про псевдонимы.
Правильным ответом был: В GROUP BY и ORDER BY.
Это вот такая особенность PostgreSQL.
В некоторых других СУБД псевдоним не работает даже в GROUP BY.
Что кажется логичным с точки зрения логического порядка работы операторов внутри системы.
В HAVING и WHERE псевдоним точно не работает, т.к. сам SELECT работает позже чем эти два.

🧠 SQL-запрос, который должен знать каждый аналитик: накопительный итог в PostgreSQL.

Если ты работаешь с аналитикой данных, рано или поздно понадобится накопительный итог:
выручка по дням, количество пользователей, прогресс метрик и т.д.

❌ Многие начинают с подзапросов и GROUP BY
✅ Но в PostgreSQL это решается одной оконной функцией

Разберём на примере.

Допустим, есть таблица orders:

order_date    | amount
--------------+--------
2024-01-01    | 100
2024-01-02    | 200
2024-01-03    | 150

Нужно посчитать накопительную сумму продаж по дням.

🔥 Правильный SQL-запрос:

SELECT
      order_date,
      amount,
      SUM(amount) OVER (ORDER BY order_date) AS running
FROM orders
ORDER BY order_date;

📌 Что здесь происходит

- SUM(amount) — считаем сумму
- OVER() — превращает агрегат в оконную функцию
- ORDER BY order_date — задаёт порядок накопления

👉 PostgreSQL сам «идёт» по строкам и суммирует значения.

Результат будет таким:

order_date  | amount| running
------------+-------+--------
2024-01-01  |   100 |  100               
2024-01-02  |   200 |  300   
2024-01-03  |   150 |  450   

💡 Почему это важно:

- без подзапросов
- читаемый SQL
- часто спрашивают на собеседованиях по SQL

Если ты изучаешь SQL, PostgreSQL и аналитику данных, оконные функции — обязательный пункт.

🕒 7 полезных функций для работы с датами и временем в PostgreSQL.

Если ты работаешь с SQL, то рано или поздно упрёшься в даты.
Фильтры, группировки, периоды, интервалы — всё это про них.

Разберём 7 функций PostgreSQL, которые реально нужны в работе.

1️⃣ NOW() — текущее дата и время:

SELECT NOW(); — 2025-12-16 14:23:10.456

Используется, когда нужно «текущее состояние» — сейчас, в этот момент.

2️⃣ CURRENT_DATE — текущая дата (без времени):

SELECT CURRENT_DATE; — 2025-12-16

Удобно для фильтрации по дням.

3️⃣ DATE_TRUNC() — усечение даты:

SELECT DATE_TRUNC('month', '2025-12-16'); — 2025-12-01 00:00:00

Очень часто используется для:

- группировки по месяцам
- неделям
- дням

4️⃣ AGE() — разница между датами:

SELECT AGE('2025-12-16', '2025-11-10'); — 1 mon 6 days

Возвращает разницу в удобном формате, а не просто число дней.

5️⃣ EXTRACT() — получить часть даты:

SELECT EXTRACT(YEAR FROM '2025-12-16');— 2025

Можно извлекать: YEAR, MONTH, DAY, HOUR, WEEK и т.д.

6️⃣ INTERVAL — работа с периодами времени

SELECT '2025-12-16'::date + INTERVAL '7 days'; — 2025-12-23

Незаменимо для:

- расчёта дедлайнов
- временных окон
- анализа периодов

7️⃣ TO_CHAR() — форматирование даты:

SELECT TO_CHAR('2025-12-16', 'YYYY-MM'); — 2025-12

Используется, когда нужно красиво вывести дату в отчётах.

🐘 Чем на самом деле занимаются администраторы баз данных (DBA).

Про DBA часто думают так:

«Ну… это человек, который следит, чтобы база не упала».

И да — это правда.
Но это лишь процентов 10 от того, чем DBA занимается на самом деле.

Разберёмся 👇

🔧 1. DBA отвечают за надёжность данных

Для бизнеса данные — это деньги, клиенты и история.
DBA делают всё, чтобы:

- данные не пропали
- данные не повредились
- данные можно было восстановить

Бэкапы, репликации, тесты восстановления — их ежедневная рутина.

⚡️ 2. DBA борются за производительность

Если запросы вдруг стали «тормозить»,
скорее всего, DBA уже это заметил.

Они:

- анализируют планы выполнения
- ищут узкие места
- настраивают индексы
- оптимизируют конфигурацию БД

И делают так, чтобы система выдерживала рост нагрузки.

🔐 3. DBA отвечают за безопасность

Кто имеет доступ к данным?
Кто может читать, кто — изменять, а кто — только смотреть?

DBA настраивают:

- роли и права
- доступы
- защиту от случайных и неслучайных ошибок

Чтобы данные не «утекали» и не ломались.

🚑 4. DBA — первые, кого будят ночью

Если база «легла» в 3 часа ночи —
DBA узнаёт об этом первым.

Он:

- ищет причину
- поднимает систему
- минимизирует потери
- делает выводы, чтобы это не повторилось

Спокойствие продакшена — их заслуга.

🧠 5. DBA — это про системное мышление

Хороший DBA понимает не только базу данных, но и:

- как работает приложение
- как идут запросы
- как растёт нагрузка
- где может возникнуть проблема

Они думают на несколько шагов вперёд.

🏁 Итог

DBA — это не просто «админ базы».
Это инженер, который делает так, чтобы бизнес мог спокойно работать, масштабироваться и не бояться за свои данные.

Если база работает стабильно и быстро —
скорее всего, где-то рядом есть хороший DBA.

UNION, EXCEPT, INTERSECT — операции объединения множеств в SQL.

В SQL есть мощный инструмент, про который знают не все,
но который сильно упрощает запросы — операции над множествами.

Если коротко:
они позволяют объединять и сравнивать результаты запросов.

Разберёмся 👇
------------------------------------------------------------------
🔹 UNION — объединить результаты

UNION объединяет результаты двух запросов и убирает дубликаты.

SELECT user_id FROM users_2024
UNION
SELECT user_id FROM users_2025;

Получим всех уникальных пользователей за два года.

Если дубликаты нужны — используйте UNION ALL.

------------------------------------------------------------------
🔹 INTERSECT — найти общее

INTERSECT возвращает только те строки,
которые есть в обоих результатах.

SELECT user_id FROM paid_users
INTERSECT
SELECT user_id FROM active_users;

Пользователи, которые и платят, и активны.


------------------------------------------------------------------
🔹 EXCEPT — найти разницу

EXCEPT показывает строки,
которые есть в первом запросе, но отсутствуют во втором.

SELECT user_id FROM users
EXCEPT
SELECT user_id FROM banned_users;

Все пользователи, кроме заблокированных.

------------------------------------------------------------------
⚠️ Важно помнить

Чтобы операции работали корректно, необходимо:

- одинаковое количество колонок
- одинаковые типы данных
- одинаковый порядок колонок

И да — порядок запросов в EXCEPT имеет значение.

Когда это реально полезно:

- сравнение сегментов
- анализ изменений
- поиск пересечений аудиторий
- очистка данных
- сложная аналитика без лишних JOIN’ов

История о том, как LEFT JOIN превратился в INNER JOIN, но никто этого не заметил.

Был у меня запрос. Красивый, аккуратный, должен был выводить все заказы, даже те, которые НЕ в статусе 'paid'.

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id
WHERE p.status = 'paid';

Смотрю — LEFT JOIN.
Думаю: ну всё правильно, хотим же заказы, даже если оплаты нет.

Запрос работает. Данные возвращает. Прод живёт.

Проходит время.

Приходит вопрос:
— А почему у нас пропали заказы без оплаты? У нас что все заказы только оплаченные?

Я открываю запрос, смотрю ещё раз.
LEFT JOIN — есть.
Вроде всё логично.

А потом PostgreSQL тихо так подсказывает:
— Друг, ты уверен, что это LEFT JOIN?

Я отвечаю:
— Уверен, написано же LEFT JOIN !!

Он продолжает:
— У тебя в запросе условие WHERE p.status = 'paid' —
это не фильтр таблицы orders.
Это фильтр результата после JOIN.

— И для строк, где оплаты нет,
p.status равен NULL.

— А NULL = 'paid' — это не TRUE.
Это ничего. Поэтому я просто выкидываю эти строки.

В этот момент LEFT JOIN:
— Я вообще-то был левым…

А WHERE отвечает:
— Был. Теперь ты INNER.

Исправление оказалось простым, условие нужно было перенести в LEFT JOIN:

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id AND p.status = 'paid';

Вывод:
LEFT JOIN — не гарантия того, что строки сохранятся.
Одно условие в WHERE — и вы сами превращаете его в INNER JOIN.

PostgreSQL не ошибается.
Он просто выполняет то, что вы написали.
Даже если вы написали это «логично».

🎄 Друзья, вот и подходит к концу 2025 год.

Предлагаю оставить в нём всё лишнее:
ошибки, сомнения, неудачные запросы.

А всё нужное и ценное — опыт, знания, идеи и желание развиваться —
смело забираем с собой в 2026 год.

Уверен, впереди нас ждёт год интересный, технологичный и полный новых открытий.
Пусть будет больше удачных решений, роста, уверенности в себе
и, конечно, достижения всех поставленных целей.

Мотивации, энергии и времени на то, что действительно важно.
И не забываем продолжать качаться и обучаться —
в наше время это уже не цель, а верный спутник на всю жизнь.

С наступающим Новым 2026 годом! 🚀
Пусть он будет сильным, продуктивным и по-настоящему вашим.

Мы часто слышим, что искусственный интеллект отнимет у людей работу, сделает профессии ненужными и вытеснит человека из привычного мира. Этот страх понятен, но если убрать эмоции и посмотреть на происходящее честно, становится видно: ИИ не уничтожает людей, он убирает всё нечеловеческое.

ИИ не является разумом в человеческом смысле. У него нет желаний, целей, намерений, понимания смысла или ответственности за последствия. Он не думает и не выбирает — он анализирует прошлое, находит закономерности и делает прогнозы. Любое «решение» ИИ — это не выбор, а статистическое предположение, основанное на исторических данных и совпадениях похожих ситуаций. Он всегда смотрит назад, даже когда кажется, что он смотрит в будущее.

Именно поэтому ИИ так хорошо справляется с рутиной, шаблонами, инструкциями и повторяющимися задачами. Он отлично воспроизводит то, что уже было, и масштабирует опыт прошлого. Но он не понимает, когда мир меняется, правила ломаются, а контекст становится новым.

Исчезают не профессии, исчезают роли-исполнители. Если работа человека сводится к выполнению формализованных действий по инструкции, эту инструкцию рано или поздно можно автоматизировать. ИИ не увольняет людей — он просто показывает, где человек давно перестал быть человеком и стал функцией.

Парадокс нашего времени в том, что чем умнее становятся машины, тем важнее становится человек. Но не как набор навыков или источник ручного труда, а как носитель смысла и ответственности. ИИ может предложить тысячу вариантов, построенных на прошлом опыте, но выбрать правильный в новой, неопределённой ситуации всё ещё должен человек.

Мы долго верили, что решающим фактором являются только хард-скиллы, а всё остальное — вторично. ИИ разрушил этот миф. Сегодня настоящей ценностью становятся умение мыслить, видеть контекст, задавать правильные вопросы, договариваться, чувствовать людей и брать на себя ответственность там, где нет готовых данных и нет правильного ответа в истории.

Самая большая опасность заключается не в том, что ИИ станет разумным, а в том, что люди начнут передавать решения системам, которые умеют только прогнозировать, но не понимать ценности. Опасен не искусственный интеллект, а желание снять с себя ответственность и спрятаться за алгоритмом.

Будут ли потери и болезненные изменения? Да. Профессии будут меняться, привычные роли исчезать, а многим придётся переучиваться. Но выиграют не самые умные и не самые технически подкованные, а самые гибкие — те, кто умеет учиться, мыслить и общаться.

ИИ не делает человека ненужным. Он делает ненужным всё то, что в человеке было не-человеческим. И, возможно, впервые за долгое время нам придётся вернуться к тому, что всегда отличало нас от машин: мышлению, ответственности и способности быть живыми.

Ребята, всем привет 👋
Наконец-то добрался до запуска — сайт с SQL-тренажёрами и тестами по PostgreSQL вышел в продакшн 🚀

Сейчас на платформе:

- базовый SQL-тренажёр
- продвинутый SQL-тренажёр
- несколько тестов по SQL и PostgreSQL

Сейчас это всё бесплатно, нужно только зарегистрироваться на сайте.

Если вам интересно потренироваться в решении SQL-задач или проверить свои знания — буду рад, если заглянете и попробуете тренажёры.

🔹 Внутри каждого тренажёра есть встроенный форум прямо на сайте — можно обсуждать решения, помогать друг другу и разбирать сложные моменты по ходу обучения.

Также есть отдельная группа в ТГ:

- ветки для каждого продукта
- общая ветка
- обратная связь

Буду очень благодарен за любые отзывы: баги, ошибки, пожелания, идеи и комментарии — всё это можно писать в соответствующих ветках группы в ТГ. Это действительно поможет сделать платформу лучше.

Платформа будет дальше развиваться и расширяться — в планах вырастить её в полноценную, увлекательную образовательную платформу не только по SQL.

В ветках по продуктам можно обсуждать конкретные задания, подходы к решениям и ситуации, когда что-то не получается.

Спасибо всем, кто поддержит 🙏

Ссылка на сайт: https://smartgatepro.ru/
Ссылка на группу сайта в ТГ: t.me/smartgate_pro

Нужно вывести все заказы, кроме оплаченных.

Запрос выглядит предельно логично:

SELECT *
FROM orders
WHERE status != 'paid';

В голове всё быстро:

— paid не нужен → выкидываем Alice и Evan
— shipped, cancelled, returned — подходят
— NULL? Ну, вроде бы тоже не paid

В уме получается:
Bob ✔️
Charlie ✔️
Diana ✔️
Frank ✔️
Grace ✔️

Итого: 5 строк.

Запрос выполняется.

PostgreSQL возвращает… 3 строки.

Без Diana.
Без Frank.

Два заказа просто исчезли.

В этот момент PostgreSQL спокойно уточняет:

— А ты уверен, что NULL != 'paid' — это TRUE?

Потому что для PostgreSQL:

NULL != 'paid'

— это не TRUE
— и не FALSE
— это UNKNOWN

А в WHERE проходят только строки, где условие TRUE.

NULL не «не равно».
Он просто неизвестен.

И WHERE отвечает:

— Не уверен? Значит, эти строки не берём в результат.

Вывод неприятный, но полезный:

!= не означает «всё, кроме этого значения».
С NULL это правило ломается.

PostgreSQL не теряет строки.
Он просто выполняет запрос буквально.

Даже если в голове всё выглядело очевидно.

Частая ошибка мышления 👇
«Если запрос работает — значит он хороший»

Запрос может быть:
– синтаксически правильным
– логически верным
– возвращать нужный результат

И при этом быть плохим.

Почему? В общих чертах.

🔹 Он делает больше работы, чем нужно
Запрос может сначала собрать «лишнее», а потом отбросить.
Результат тот же, а усилий — больше.

🔹 Он неудобен для базы данных
Некоторые формулировки выглядят логично для человека,
но неудобны для PostgreSQL.
База не «понимает смысл» — она выполняет шаги.

🔹 Он плохо читается
Если запрос сложно понять с первого раза,
его сложно поддерживать, менять и оптимизировать.
А значит, проблемы — вопрос времени.

🔹 Он хорошо работает только сейчас
На небольших таблицах разницы почти не видно.
Но при росте данных такой запрос начинает резко «дорожать».

Главная мысль простая:
👉 Правильный результат ещё не делает запрос хорошим

Хороший запрос — это не только что он вернул,
но и насколько аккуратно он это сделал:
– без лишней работы
– понятно для человека
– спокойно при росте данных

И именно здесь начинается взрослая работа с SQL на уровне мышления.

Очень часто в SQL проблемы начинаются ещё до первого SELECT.
С формулировки задания. С того, что человек либо не дочитал её до конца, либо понял «примерно» («ну, вроде понятно, сейчас напишу»).

Сначала нужно чётко ответить себе на простой вопрос: что именно от меня хотят получить в результате?
Не какие таблицы, не какие JOIN’ы или другие инструменты я буду применять — а какой смысл у ответа. Пока этого понимания нет, любой SQL будет стрельбой вслепую.

После этого имеет смысл открывать схему БД.
Смотреть, какие таблицы есть, за что каждая отвечает, что на самом деле лежит в столбцах и какие данные нужны для решения задачи.
В этот момент половина запроса уже готова — ты не придумываешь решение, ты его находишь.

И даже когда запрос отработал, работа не закончена.
Нужно вернуться к заданию, перечитать его и сравнить с результатом:
Он точно отвечает на вопрос?
Совпадает ли смысл данных, а не просто количество строк.

SQL — это не про скорость набора.
Это про умение сначала подумать, а потом проверить, что ты решил именно ту задачу, которую просили.

Сегодня простая задачка. Ниже нужно ответить в режиме викторины.

Всем привет. Разберем вчерашнюю викторину про LEFT JOIN.

Ключевая идея: JOIN умножает строки

LEFT JOIN делает так:

Берёт каждую строку из левой таблицы (orders) — все заказы сохраняются в результате при любых условиях.

Для каждого заказа ищет все подходящие строки в правой таблице (order_details).

Если подходящих строк несколько — заказ “размножается”: будет столько строк результата, сколько совпадений найдено.

Если совпадений нет — всё равно будет 1 строка, но поля из правой таблицы будут NULL.

Разбираем по каждому заказу:

✅ Заказ order_id = 1

В order_details есть две строки с order_id = 1.

Это значит:
1 заказ × 2 совпадения = 2 строки в результате

✅ Заказ order_id = 2

В order_details есть одна строка с order_id = 2.

Значит:
1 заказ × 1 совпадение = 1 строка

✅ Заказ order_id = 3

В order_details нет строк с order_id = 3.

Но это LEFT JOIN, поэтому заказ не пропадёт:
1 заказ без совпадений = 1 строка с NULL справа

Итого по математике:

Для order_id = 1 → 2 строки
Для order_id = 2 → 1 строка
Для order_id = 3 → 1 строка

2 + 1 + 1 = 4 строки ✅

Начал замечать одну вещь.

Когда ИИ отвечает слишком уверенно,
я начинаю перепроверять.

Когда отвечает неуверенно,
я начинаю перепроверять.

Когда пишет:

«Я могу ошибаться, но…»
— я точно иду перепроверять.

В итоге ИИ стал самым полезным инструментом для развития навыка критического мышления.

Раньше ты сомневался в себе.
Теперь — в ответе модели.

Прогресс ? Прогресс.

И если честно, это хороший знак.
Значит, мы всё ещё думаем головой, а не просто копируем результат.

Хороших выходных 👌
И да — перепроверяйте. Всегда.

("Даже этот пост.")

Зачем в PostgreSQL делать резервные копии?

Иногда кажется, что резервные копии — это что-то из разряда
«на всякий случай» и «потом настроим».

До первого раза.

PostgreSQL — надёжная система.
Но резервные копии делают не потому что PostgreSQL плох,
а потому что мир вокруг него — неидеален.

1️⃣ Человек ошибается (и это нормально)

Самая частая причина потери данных — человеческий фактор.

- DELETE без WHERE
- UPDATE без условия
- TRUNCATE, DROP
- «Я просто хотел проверить»
- «А можно откатить?»

PostgreSQL честно выполняет команды.
Он не понимает, что это была ошибка.

Резервная копия — это возможность вернуться назад, а не разбираться с последствиями.

2️⃣ Техника ломается без предупреждения

Диски выходят из строя.
Файловые системы повреждаются.
Виртуальные машины могут быть утеряны.

("Обычно ночью. В пятницу.")

Если данных нет в резервной копии — их больше не существует.

3️⃣ Данные могут быть испорчены незаметно

Иногда данные не удаляются, а портятся:

- некорректная логика приложения
- ошибки в расчётах
- неверные массовые обновления
- неправильное отключение питания, падения сервера во время записи

Проблема может обнаружиться не сразу.
И вот здесь важно иметь бэкап за нужную дату, а не только «вчерашний».

Какие бывают типы резервного копирования в PostgreSQL?

🔹 Логическое резервное копирование

Инструменты:

- pg_dump
- pg_dumpall

Что это:

- сохраняется структура и данные в виде SQL или архивов
- можно восстановить отдельные таблицы или базы (настраивается)

Плюсы:

- гибкость
- удобно переносить данные
- легко работать в большинстве случаев

Минусы:

- медленнее
- не подходит для очень больших баз

🔹 Физическое резервное копирование

Инструменты:

- pg_basebackup
- копирование каталога данных

Что это:

- снимается копия всех файлов базы данных
- восстанавливается всё целиком (весь кластер)

Плюсы:

- быстро
- подходит для больших объёмов данных

Минусы:

- нельзя восстановить отдельную таблицу
- жёстко привязано к версии PostgreSQL
----------------------------------------------------------------------------------------
Важная мысль напоследок.

Резервное копирование — это не паранойя.
Это базовая гигиена работы с данными.

PostgreSQL делает всё, чтобы данные хранились корректно.
А задача человека — сделать так, чтобы они не пропали навсегда.

("Лучший бэкап — тот, который уже есть и который проверяли.")