Таблицы в базах данных: где чаще всего "горит"

Когда мы слышим слова таблица, то сразу идет ассоциация со строками и столбцами. Но в базе данных - это не просто строки и столбцы, это мини вселенная со своими правилами и требованиями.

В своем канале На связи: SQL я рассказываю об особенностях языка SQL. Разбираю аналитические запросы и подходы работы с данными. Канал создала недавно с нулем подписчиков, но там уже есть интересная информация для работы аналитиков. Подписывайся!

И для формирования таблиц в БД есть свои требования, нюансы и особенности.

Очень часто аналитики сталкиваются со следующими проблемами при работе с данными:

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

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

Грубо говоря, нормализация - это способ организации данных. Что именно хранится, где именно хранится и как все, что хранится, связано между собой.

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

Это приводит к сложности обновления — изменил телефон в одном месте, а в другом он остался старым; объем БД растет, что требует увеличения ресурсов для работы с данными.

В этом случае необходимо выносить повторяющиеся данные в отдельные таблицы и связывать ключами.

И это тоже про нормализацию данных.

Есть поле, но оно ничем не заполнено. И тогда аналитик задается вопросом: что это значит? Что данных просто нет (их никто не вносит), данные вносят, но они потерялись при загрузке в таблицу, либо эти данные необходимо воспринимать как равные нулю...

В этом случае необходимо сначала посмотреть требования к источнику данных, есть ли там обязательность их заполнения. Если данные обязательны к заполнению, то стоит рассмотреть ETL (Extract Transform Load - извлечение, преобразование и загрузка) процесс данных.

И от полученных результатов принимать решение как расценивать NULL данные.

Телефон хранят как INT, даты — как текст, деньги — как FLOAT.Такой подход приводит к тому, что в телефоне «съедается» +7, даты не сортируются, а деньги теряют копейки.

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

В этом случае: только правильное использование типов данных.

Нет ключей и индексов

Ключи нам нужны, чтобы однозначно идентифицировать данные и связывать таблицы между собой.

Есть первичный ключ (Primary Key) и внешний ключ (Foreign Key)
Первичный ключ - это уникальный идентификатор.
Например есть два Ивановых Ивана Ивановича, но у них будут разные ID. Этот ID будет однозначно идентифицировать каждого из них.
Внешний ключ - это ссылка на другую таблицу. Например есть таблица заказов и в ней есть поле client_id. Это поле будет ссылаться на ID нашего Иванова Ивана Ивановича в таблице с персональными данными.

Индексы нам нужны для ускорения поиска.

Представь, у тебя есть огромная книга (миллионы строк в таблице). Если ты ищешь слово вручную — придётся листать страницу за страницей.

Но если есть алфавитный указатель (индекс) — ты сразу находишь нужное слово.

Примеры:

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

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

А в канале На связи: SQL уже первые посты про структуры запросов и JOIN ждут тебя.

Если тебе нужна поддержка и мотивация или просто сопутствующие слова для твоего развития, то приходи в канала Сила слов. Там каждое утро тебя ждет мотивационное и поддерживающее послание.