Когда мы слышим «COUNT» и «SUM» мы подразумеваем - «считает строки», «суммирует числа»

Но даже для таких действий есть тонкости и нюансы.

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

В большинстве случаев мы используем 3 вида COUNT

• COUNT(*) — считает все строки, даже пустые.

• COUNT(column) — считает только те строки, где есть данные.

• COUNT(DISTINCT column) — считает уникальные значения в column.
  

Рассмотрим на конкретном примере:

| id | name | gift |
-------------------------------
| 1 | Оля | Торт |
| 2 | Вася | NULL |
| 3 | Маша | Цветы |
| 4 | Петя | Торт |
| 5 | Катя | NULL |
| 6 | Оля | Торт |

COUNT(*)

Считаем все строки, независимо от содержимого колонок:

SELECT COUNT(*) FROM guests;

Результат: 6

• Всего 6 гостей пришло.

• Неважно, принес ли кто-то подарок или нет, учитывается каждая строка.

COUNT(gift)

Считаем только те строки, где колонка gift не NULL:

SELECT COUNT(gift) FROM guests;

Результат: 4

• Только Оля (Торт), Маша (Цветы), Петя (Торт), Оля (Торт) учитываются.

• Вася и Катя, у которых gift = NULL, не считаются.

• Эта разница показывает: сколько записей реально имеют данные по этой колонке.

COUNT(DISTINCT gift)

Считаем уникальные подарки:

SELECT COUNT(DISTINCT gift) FROM guests;

Результат: 2

• Есть только два уникальных подарка: Торт и Цветы.

• Независимо от того, сколько гостей принесли одинаковый подарок, каждый подарок считается один раз.

🔍 Что это говорит при анализе данных

• COUNT(*) — общее количество записей (все строки).

• COUNT(column) — сколько строк с заполненным значением в колонке.

• COUNT(DISTINCT column) — сколько уникальных значений встречается в колонке.

Вывод: разница между этими числами может показать пропуски (NULL) и повторяющиеся данные. Это важно при анализе — если просто взять COUNT(*), можно недооценить проблему с пропущенными значениями.

Ну а теперь рассмотрим SUM

Чтобы показать, как эта функция работает и какие тонкости бывают, рассмотрим таблицу:
Таблица orders:
| id | customer | amount |
| -- | -------- | ------ |
| 1 | Оля | 100 |
| 2 | Вася | NULL |
| 3 | Маша | 200 |
| 4 | Петя | 150 |
| 5 | Катя | NULL |
| 6 | Оля | 100 |

1️⃣ SUM(amount)
Считаем сумму по колонке amount (игнорирует NULL):

SELECT SUM(amount) FROM orders;

Результат: 550

• Складываются только числа: 100 + 200 + 150 + 100 = 550

• NULL не учитываются

• Если бы все значения были NULL, результат был бы NULL, а не 0

2️⃣ SUM(DISTINCT amount)

Считаем сумму уникальных значений:

SELECT SUM(DISTINCT amount) FROM orders;

Результат: 450

• Уникальные значения amount: 100, 150, 200

• Складываем их: 100 + 150 + 200 = 450

• Показывает, сколько реально различных сумм встречается, игнорируя повторения
  узнаем, сколько различных сумм клиенты реально платят.

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

🔍 Важные моменты

1. NULL не участвуют — всегда нужно помнить, что SUM(column) не считает NULL.

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

3. Суммирование строк с пропусками — может дать неожиданное ощущение «потери данных».

Вывод:

• SUM(column) = фактическая сумма всех чисел

• SUM(DISTINCT column) = сумма только уникальных чисел

• Важно учитывать NULL, иначе можно получить неожиданные результаты

NULL — это специальное значение в SQL, которое означает отсутствие данных или неизвестное значение. Важно понимать, что NULL ≠ 0 и NULL ≠ пустая строка (‘’).

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. И пост про NULL уже ждет тебя! Присоединяйся!

NULL не равен ничему, даже самому себе. Не является числом, строкой или другим типом данных.

И это надо запомнить при работе с данными.

Все что вы будете сравнивать с NULL будет возвращаться как UNKNOWN.

Для работы с NULL есть специальные операторы.

-- Проверка на NULL

SELECT *

FROM table

WHERE column IS NULL;

-- Проверка на НЕ NULL

SELECT *

FROM table

WHERE column IS NOT NULL;

-- Замена NULL на значение

SELECT COALESCE(column, 'значение_по_умолчанию')

FROM table;

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

Вообще, понятие NULL появилось в начале 1970-х годов. Разработчики реляционных БД специально создали такое значение для обозначения отсутствия данных. Это было революционным решением, позволившим хранить информацию более гибко.

Математические фокусы с NULL:

• Любое число + NULL = NULL

• NULL * 100 = NULL

• NULL / 2 = NULL

• Индексы могут работать медленнее при наличии NULL

• Некоторые типы индексов вообще не поддерживают NULL

• Агрегатные функции игнорируют NULL по умолчанию

Ну и коротко про то что такое Но(у)ль:
Ноль — это чётко определённое значение:

• Числовое значение

• Имеет математический смысл

• Участвует в вычислениях

• Равно самому себе

А теперь про пусто:
Пустота — отсутствие содержимого

Пустое значение может быть:

• Пустой строкой (‘’ или “”)

• Пустым массивом

• Пустым объектом

• Имеет конкретный тип данных

Рекомендации:

• Используйте NULL для неизвестных данных

• Применяйте 0 для числовых значений по умолчанию

• Используйте пустые строки для незаполненных текстовых полей

Заключение

Помните: каждое из этих значений несёт свой смысл. Неправильное использование может привести к:

• Ошибочным расчётам

• Некорректной логике

• Потерям данных

• Системным ошибкам

А как вы работаете с этими значениями в своих проектах? Поделитесь опытом в комментариях!

Моё недавнее книжное приобретение.

Это не обложка с приколом, это текст на заявленную тему и на полном серьёзе. Книжная серия “Сталинский букварь”. Там 53 страницы. И это были тяжелые 53 страницы. В силу зашкаливающего пустословия. Бла-бла, читать-читать, бла-бла. Под конец идет несколько полезных практических советов, довольно общо написанных. Читательские дневники, конспекты, выписки. Всё вроде уместно, всё полезно было бы для саморазвития, но изложить эти полезные советы можно на 1-2 страницах, а не на 53.

Написано, что автор - профессор философии Поварнин. Судя по Википедии это ученый с серьезными трудами по логике. У данной брошюры тоже автор он, но, думаю, не совсем. Дело в том, что текст (это в предисловии сказано) родился из его доклада по теме на какой-то конференции где-то в 20-х годах. А брошюра из 60-х. Она и корректировалась и переписывалась и делалась брошюрой из доклада. Подозреваю, что текст доклада раздули для солидности. И делал это уже не Поварнин.

Вообще в те годы это был целый жанр. Я его называю: “Как правильно какать”. То есть писались книги о том как переводить с иностранного, как писать литературу. Ну и вот как читать книги. Всё объяснялось на пальцах. Последствия истребления образованного слоя. Надо же как-то новых специалистов обучать. Вот такое и писалось.

Нет, на самом деле, скажите спасибо, что 53 страницы, а не 530. Книга, повторюсь, (или брошюра) 60-х годов, тогда нормально растягивать не умели так, как сейчас умеют. А секрет-то прост – добавьте примеров. Ну знаете все эти книжки об успехе, продажах, бизнесе и психологических приёмах в духе бихевиоризма?

Сын моей подруги Дженнифер переодевался в женское платье и участвовал в нелегальных боях без правил. Дженнифер не знала, делать. Поэтому я посоветовал ей давать сыну по 10 долларов за каждый хорошо подобранный наряд, когда сумочка, туфли и платье хорошо сочетаются. И благодаря моему совету проблема была решена – Дженнифер отказалась от общения со мной навсегда.

Вот и с чтением для самообразования так можно. Примеры – это даже не вода и пустословие, точнее они так не воспринимаются. Смысла в них ноль, они фальшивы и выдуманы на 100%, но пока мы читаем, мы как будто читаем факты. Подсознательно что ли идентифицируем это как факты – не знаю. В общем эту белиберду читать легко и приятно.

Моя подруга Дженнифер была матерью-одиночкой 8 детей, в Рязани, в начале 90-х. Она мечтала о лучшей работе, чтобы прокормить детишек. Помню, тогда я посоветовал ей больше читать для самообразования, а главное - вести читательский дневник и конспектировать наиболее интересные места. Дженнифер благодаря моему совету научилась многому. В 96 году она открыла свою консалтинговую компанию и зарабатывала большие по тем временам деньги. Пока в 98 году её тонированный мерседес не обстреляли из пулемёта, нанятые конкурентами киллеры.

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

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

DELETE как цифровой пылесос**, который может убрать всё, что вы ему скажете. Только вот вернуть обратно будет ой как непросто!

А пока подписывайся на мой канал На связи: SQL Там я публикую посты про особенности и нюансы SQL. Этот канал про то, как не бояться баз данных, понимать, что такое JOIN, GROUP BY и почему NULL ≠ 0. Его я веду с нуля подписчиков. Присоединяйся!

Базовый синтаксис:

DELETE FROM таблица
WHERE условие;

Можно использовать EXISTS с подзапросами

DELETE FROM orders

WHERE EXISTS (

SELECT 1

FROM customers

WHERE customers.id = orders.customer_id

AND customers.status = 'deleted' );

Удаляет заказы неактивных клиентов.

Можно использовать JOIN

DELETE o

FROM orders o

INNER JOIN customers c ON o.customer_id = c.id

WHERE c.registration_date < '2020-01-01';

Удаляет заказы клиентов, зарегистрированных до 2020 года.

Как происходит удаление записей?

Физическое удаление в SQL — это не мгновенное стирание данных с диска. Когда вы выполняете DELETE:

• Система записывает операцию в журнал транзакций

• Помечает удалённые строки как свободные

• Физическое место может быть использовано для новых данных

• Сами данные остаются в файле некоторое время

Формируется основной файл .mdf (или аналогичный). Также информация записывается в журнал транзакций. Сроки хранения удаленных данных зависят от:
- модели восстановления базы данных
- активности базы данных
- настроек резервного копирования
- объема свободного места

Удаленные данные могут храниться до следующего бэкапа или до перезаписи журнала.

Способы восстановления данных после DELETE

1. Восстановление из резервной копии

   RESTORE DATABASE имя_базы FROM DISK = 'путь_к_бэкапу'

2. Использование моментальных снимков (Snapshot)

   CREATE DATABASE имя_снимка

   ON (NAME = имя_файла, FILENAME = 'путь_к_файлу')

   AS SNAPSHOT OF исходная_база;

   Восстановление данных из снимка:

   INSERT INTO исходная_таблица

   SELECT * FROM снимок.dbo.таблица

3. Восстановление через LSN (Log Sequence Number)

   Если есть журналы транзакций:

   BACKUP LOG имя_базы TO DISK = 'путь_к_журналу'

   Поиск удалённых записей:
   SELECT [Current LSN], [Transaction ID]

   FROM fn_dblog(NULL, NULL)

   WHERE Operation = 'LOP_DELETE_ROWS'

4. Либо использовать специальные посторонние программы для восстановления БД

Чтобы предотвратить потерю данных:

• Регулярно создавайте резервные копии

• Используйте транзакции (BEGIN TRANSACTION / ROLLBACK)

• Тестируйте DELETE-запросы на тестовой базе

• Применяйте WHERE с осторожностью

• Настройте политики резервного копирования

DELETE vs TRUNCATE

Многие думают, что TRUNCATE и DELETE — это одно и то же. На самом деле:

• DELETE удаляет строки по одной и записывает каждую операцию в журнал транзакций

• TRUNCATE мгновенно очищает таблицу, минуя журнал (кроме некоторых случаев)

При выполнении DELETE:

• Блокируются только удаляемые строки

• Другие транзакции могут читать незаблокированные данные

• В некоторых СУБД возможна эскалация блокировок до уровня таблицы

• Не затрагивает структуру индексов

• Индексы остаются в прежнем состоянии

• Это ускоряет процесс удаления

• Не сбрасывает счётчики автоинкремента

• Сохраняет текущее значение последовательности

• Важно при работе с первичными ключами

• Активируются триггеры AFTER DELETE

• Можно отслеживать удалённые строки через виртуальную таблицу deleted

• Триггеры могут отменить операцию удаления

Чтобы сохранить целостность данных можно использовать ON DELETE CASCADE
Это позволит там, где есть зависимость по внешним ключам произвести удаление зависимых строк.