Кто едет на ЛАФ? признавайтесь)))

Кажется, мне пора открывать свое hr-агентство... а пока попробуем здесь :)

📣 ищу аналитика уровня middle и выше на интересный банковский проект . нужен хороший технический бекграунд (sql, очереди и всякое такое)
есть желающие?

Выбор СУБД

Разобрались с типом БД. Но в каждом типе представлено много разных моделей СУБД. Как понять, какую выбрать? Правда ли, что каждая СУБД хороша для своих задач?
Рассмотрим особенности каждой из популярных СУБД и рекомендации по выбору.
📌 Сохраняйте себе, чтобы быстро найти эту памятку, когда будете выбирать СУБД для проекта.

🕹 MySQL

Особенности
- Открытый исходный код, распространенная среди разработчиков.
- Поддерживает реляционную структуру данных (таблицы, строки).
- Подходит для простых запросов и относительно небольших объемов данных.
- Хорошо интегрируется с PHP и JavaScript фреймворками.

Рекомендуемые задачи
- Веб-приложения с небольшими нагрузками (например, блоги, небольшие корпоративные порталы).
- Простые системы учета товаров/заказов/сотрудников.
- Хранение структурированных данных, требующих строгих отношений между таблицами.


🕹 PostgreSQL
Особенности
- Более мощная альтернатива MySQL с поддержкой сложных SQL-запросов и расширенных функций.
- Гибкая поддержка транзакций ACID, оптимизированная работа с большими объемами данных.
- Возможность создавать расширения, хранимые процедуры и триггеры.

Рекомендуемые задачи
- Средние и крупные проекты с большим объемом данных и сложными структурами.
- Приложения, которым важна высокая производительность и надежность.
- Географические приложения благодаря встроенной поддержке пространственных данных (расширение PostGIS).


🕹 MongoDB
Особенности
- NoSQL база данных с документоориентированной моделью хранения данных.
- Высокая гибкость схемы базы данных — возможность хранить разнородные данные без жесткой структуры.
- Отличается высокой производительностью при работе с большими массивами документов.

Рекомендуемые задачи
- Масштабируемые веб-сервисы и мобильные приложения с частым изменением структуры данных.
- Работа с полуструктурированными или слабо формализованными данными (логирование действий пользователей, социальные сети).
- Анализ больших объемов неструктурированных данных (Big Data).


🕹 ClickHouse
Особенности
- Колоночная СУБД, разработанная специально для аналитики и обработки огромных объемов данных в режиме реального времени.
- Обладает уникальной скоростью обработки аналитических запросов (OLAP), отлично масштабируется горизонтально.
- Идеальна для сбора и анализа метрик, логирования событий и построения дашбордов.

Рекомендуемые задачи
- Аналитика поведения пользователей, обработка журналов событий.
- Реалтайм-аналитические запросы и построение отчетов по данным большого объема.
- Логирование активности приложений и серверов (системы мониторинга, BI-платформы).

У кого совпало? 😆

Теперь, когда мы выбрали СУБД, можно приступать к модели данных. Эта часть является одним из моих любимых процессов при проектировании системы. Но очень редко я следую правилам. Сначала я думала, что я нетерпелива, чтобы проходить последовательно по всем процессам. А потом я поняла, что эти знания вложены в меня настолько глубоко, что я «из коробки» проектирую модель нормализованной и со всеми ключами.
Но давайте разложим по полочкам весь процесс. Будет долго, но эффективно. Такой очевидный этап как сбор требований мы пропустим и перейдем сразу к данным.

🏮Сбор и классификация сущностей
Определяется перечень объектов предметной области (сущностей), которые должны быть представлены в модели данных. Эти сущности классифицируются по типу (например, клиенты, товары, заказы)


🏮 Определение отношений между сущностями
Далее устанавливаются связи между выявленными сущностями. Например, один клиент может иметь много заказов, а один заказ может содержать несколько товаров. Связи бывают трёх типов:
- Один-к-одному (1:1)
- Один-ко-многим (1:N)
- Многие-ко-многим (N:M)

🏮 Создание концептуальной модели данных
Концептуальная модель отражает высокоуровневую структуру данных без привязки к конкретной СУБД. Обычно используется нотация ERD (Entity Relationship Diagram). Здесь отражаются сущности, их атрибуты и взаимосвязи.

🏮 Нормализация данных
Нормализация является важным этапом, целью которого является устранение избыточности данных и повышение целостности базы данных. Она заключается в последовательном приведении схемы базы данных к определённым формальным нормам (нормальные формы):

- Первая нормальная форма (1NF): Уничтожение повторяющихся групп.
- Вторая нормальная форма (2NF): Устранение частичной зависимости атрибутов от первичного ключа.
- Третья нормальная форма (3NF): Исключение транзитивной зависимости атрибутов.
- Четвёртая нормальная форма (4NF): Разделение многозначных зависимостей.
- Пятая нормальная форма (5NF): Минимизация аномалий обновления путём разбиения сложных зависимостей.

Этот процесс позволяет минимизировать дублирование данных и повысить производительность запросов.


🏮 Физическое проектирование
На данном этапе разрабатывается физическая структура базы данных, учитывающая особенности выбранной СУБД. Определяются типы полей, индексы, ограничения целостности, триггеры и другие элементы физической структуры.

Примеры решений физического уровня:
- Выбор оптимального типа поля (INT, VARCHAR, DATE и др.)
- Создание уникальных ключей и индексов для ускорения выборок.


🗝 Таким образом мы последовательно приходим к итоговому решению.
Дальше разберем подробно основные шаги.

Сбор сущностей

Потренируемся проектировать на несложном, но занимательном примере: 📔 библиотеке. 📔
Процесс стандартный: в библиотеке хранятся книги, приходят читатели, берут имеющиеся в наличии книги, а после прочтения возвращают их.

📒 Особенности и условия:
1. За просрочку возврата полагается штраф
2. Книгу можно взять домой или в читальный зал библиотеки. Статусы книги должны различаться.
3. Система предназначена не только для просмотра статуса книги, но и места ее хранения на полке

Как говорили ранее, начинаем со сбора сущностей. Напишите в комментариях, какие сущности вы бы предложили. Вечером покажу свой вариант :)

Показываю, что получилось у меня.
📘 Книга
— название книги, автор, ISBN, издательство, жанр, количество страниц, дата публикации, местоположение (полка), статус доступности (занята/свободна).

🧑‍💼 Пользователь
— ФИО читателя, номер читательского билета, контактные данные (телефон, email), адрес проживания, история взятий книг, долги (штрафы).

🧙 Автор
— имя автора, биографические сведения, список произведений.

👩‍❤️‍👨 Жанр
— литературный жанр (детектив, роман, фантастика и др.).

🏢 Отдел
— секция библиотеки (художественная литература, учебники, справочная литература и т.п.)

💸 Штрафы
— виды штрафов, размер штрафа, сроки просрочки возврата.

📑 Запись о выдаче
— книга, выданная пользователю, срок выдачи, предполагаемый срок возврата, фактический возврат, штраф (если применимо).

Следующим этапом будет определение связей между этими сущностями.

Котики, кто на ЛАФ? 😘

♻️ Концептуальная модель данных ♻️

Продолжаем последовательно делать нашу задачу. Теперь рассмотрим связи между ранее перечисленными сущностями. Это будет первой частью концептуальной модели данных.

➿ Книга и️ Автор
Один автор может написать много книг
Одна книга также может иметь нескольких авторов.
связь «многие ко многим»


➿ Книга и️ Жанр
Книга может относиться сразу к нескольким жанрам
связь «многие ко многим»

➿ Книга и️ Отдел
Книги располагаются в определенных отделах библиотеки: один отдел хранит много книг, но каждая книга находится лишь в одном отделе.
связь «один ко многим»

➿ Книга и Запись о выдаче
Каждая запись о выдаче связана с конкретной книгой: одна книга может многократно выдаваться разным пользователям, но конкретная запись относится именно к одной книге.
связь «один ко многим»

➿ Пользователь и️ Запись о выдаче
Пользователи берут разные книги в разное время: каждый пользователь может брать много книг, но отдельная запись принадлежит одному пользователю.
связь «один ко многим».

➿ Запись о выдаче и Штрафы
Если пользователь просрочил возвращение книги, появляется задолженность: одна запись о выдаче может привести к начислению одного или нескольких штрафов, но штраф всегда привязывается к конкретной записи о выдаче.
связь «один ко многим»

Следующий этап — выбор подходящей структуры хранения данных.

♻️ Концептуальная модель данных ♻️

🤜 Проанализируем тип структуры

Какие аспекты нужно учесть:
▪️наличие большого количества стандартных сущностей (книги, клиенты, штрафы);
▪️необходимость обработки отношений между этими сущностями (книга связана с выдачей клиенту, выдача связана с записью о возврате);
▪️важность гарантии целостности данных при проведении различных операций.

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


🤜 Определяем атрибуты

Для нашей несложной задачи выделим следующие таблицы и поля:

📖 Books (Книги)
- title (название)
- isbn (ISBN-код)
- authors (авторы книги) – может быть > 1
- publicationyear (год издания)
- pagescount (количество страниц)
- availabilitystatus (статус доступности)
- location (местоположение/полка)
- genre (жанр). Может быть > 1)

🧑‍🎓 Authors (Авторы)
- fullname (ФИО автора)
- biography (биография)

🧞‍♂️ Genres (Жанры)
- name (жанр)

🏛 Departments (Отделы)
- name (название отдела)

🙍 Users (Читатели)
- firstname (имя)
- lastname (фамилия)
- readerticketnumber (номер читательского билета)
- phonenumber (телефон)
- email (электронная почта)
- address (адрес проживания)

🎫 Loans (Выдачи книг)
- book (Выданная книга)
- user (Пользователь, который ее взял)
- issuedate (дата выдачи)
- returndate (предполагаемая дата возврата)
- actualreturndate (фактическая дата возврата)
– loantype (тип выдачи - читальный зал или на дом)

💸 Fines (Штрафы)
- loan (Запись о выдаче)
- amount (сумма штрафа)
- reason (причина начисления штрафа)
- status (статус, оплачен или нет)

Далее займемся приведением данных к нормальным формам.

Не забывайте правильно оценивать таски!)

☂️ Первая нормальная форма (1NF)

Наши дальнейшие преобразования покажутся вам очень простыми и очевидными, и мы могли их сделать еще 3 поста назад. Не забываем, что цель нашего разбора – просто вспомнить, что такое нормальные формы и чем они отличаются друг от друга, чтобы удовлетворить самого въедливого интервьюера на собесе :) (или просто для общего развития)

📀 Первая нормальная форма (1NF): Уничтожение повторяющихся групп.

Первая нормальная форма (1NF) означает приведение каждой сущности в такую форму, где каждое значение атрибута является простым (атомарным), а повторяющиеся группы отсутствуют. В нашей модели есть пара полей, которая подразумевает несколько экземпляров атрибута для одной строки (связь многие ко многим).

⏳ Проблема: Поле authors может содержать больше одного значения (авторов). Это нарушает правило 1-й НФ, поскольку должно быть одно значение на одну строку.

⌛️Решение: Разбиваем этот атрибут на отдельную таблицу (BookAuthors), где одна строка соответствует одному автору конкретной книги, а из таблицы книг убираем любое упоминание об авторах.

1. Books (Книги)
- title (название)
- isbn (ISBN-код)
- publicationyear (год издания)
- pagescount (количество страниц)
- availabilitystatus (статус доступности)
- location (местоположение/полка)

2. BookAuthors (Авторы книг)
- author (автор книги)
- book (книга)

3. BookGenres
– genre (жанр книги)
– book (книга)

Остальные таблицы не содержат повторяющихся групп, поэтому не подлежат исправлению.

☂️ Вторая нормальная форма (2NF) ☂️

Вторая нормальная форма (2NF): Устранение частичной зависимости атрибутов от первичного ключа.
2NF требует, чтобы все неключевые атрибуты полностью зависели от полного первичного ключа (первичные ключи могут быть составными). Нарушение возникает, когда есть зависимость неключевого атрибута лишь от части первичного ключа.
В этой части у нашей модели данных отсутствуют нарушения, поэтому для иллюстрации возьмем искуственный пример. Представим, что мы решили хранить книги со следующими атрибутами:

- BookTitle – название книги (ключ)
- DepartmentName – название отдела, где хранитс книга (история, художественная, компьютерная) (ключ)
- LocationShelf – номер стеллажа.

Атрибут LocationShelf зависит только от подразделения (DepartmentName), а от названия книги не зависит. Значит, нарушена 2NF, тк имеется частичная зависимость, а должна быть зависимость от обоих ключей.
Вопрос решается разделением одной таблицы на две:

📓Books
- BookId
- Title
- DepartmentId

🏢 Departments
- DepartmentId
- Name
- LocationShelf


☂️ Третья нормальная форма (3NF) ☂️
Исключение транзитивной зависимости атрибутов.

3NF требует отсутствия транзитивных зависимостей среди неключевых атрибутов. То есть, любой неключевой атрибут не должен зависеть от другого неключевого атрибута, кроме первичного ключа.
Всвязи с тем, что наши данные построены корректно с точки зрения 3 формы, возьмем пример:
Предположим, что информация о книге реализована так:
- ISBN – идентификатор книги
- Title – название книги
- Author – автор книги
- Reader - читатель

❓Проблемы данной структуры:

🔸 Ошибочная зависимость. Поле Reader зависит не только от уникального идентификатора книги (ISBN), но также косвенно от имени автора и названия книги. Это нарушение правил Третьей Нормальной Формы (3NF), так как возникают потенциальные аномалии модификации данных.

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

Для решения мы отделяем книг и читателей и создаем соединяющую таблицу «Выдача книг», как мы и сделали изначально.

На этом мы завершаем приведение к нормальным формам и переходим к физическому проектированию

🎲 Что делать на физическом проектировании? 🎲
В отличие от логического и концептуального уровней, физический уровень проектирования многоступенчатый и содержит несколько этапов внутри себя. Сначала мы перечислим основные из них, а затем будем смотреть, что из этого применимо к нашей «бибилиотечной» задаче

Шаги перехода к физическому проектированию:

✏️ Выбор СУБД: Определяемся с типом базы данных, которую будете использовать (MySQL, PostgreSQL, MongoDB и др.).

✏️ Определение структуры таблиц
- Какие поля будут присутствовать в каждой таблице?
- Каковы типы данных полей (строки, целые числа, даты)?

✏️ Настройка первичных ключей
- Каждое отношение должно иметь уникальный идентификатор (первичный ключ).

✏️ Создание внешних ключей
Нужно реализовать внешние ключи, обеспечивающие целостность данных. Внешний ключ ссылается на первичный ключ другой таблицы. Например, в таблице author_book внешний ключ ссылается на id автора (author_id) и id книги (book_id).

✏️ Индексация
Разобраться, есть ли необходимость в индексации и Определить индексированные поля , особенно те, по которым будут проводиться частые выборки. Индексы ускоряют выполнение SQL-запросов, связанных с поиском записей по значению ключа.

✏️ Обеспечение целостности данных:
Разобраться в необходимости использования триггеров и хранимых процедур для поддержания бизнес-правил и проверки данных на входе. Например, запрет на выдачу книги, если пользователь имеет штрафы.

✏️ Ограничения уровня БД
Добавить необходимые ограничения на уровне схемы (ограничения NOT NULL, UNIQUE, CHECK-контракты и другие правила, определяющие допустимые значения).

✏️ Оптимизация производительности
Решить, какие методы оптимизаций потребуются: разделение таблиц, горизонтальное масштабирование, репликация, шардинг и тд, в зависимости от предполагаемых нагрузок.

✏️ Шифрование чувствительной информации:
Если база данных содержит персональные данные читателей или иную конфиденциальную информацию, важно предусмотреть механизмы шифрования (либо на уровне самой базы данных, либо на уровне приложения).

📍Чекл-лист ключевых решений на этапе физического проектирования:

🟢 Создание физических схем данных (таблиц, индексов, представлений);
🟢 Настройка правил целостности и каскадных действий (ON DELETE CASCADE, ON UPDATE CASCADE);
🟢 Организация резервного копирования и восстановления данных;
🟢 Установка политик паролей и механизмов аутентификации пользователей;
🟢 Планирование инфраструктуры (расположение сервера, сетевые настройки, безопасность доступа);
🟢 Конфигурация базы данных для повышения производительности (параметры буферного кеша, временные зоны, настройка памяти).

🔑 О первичных ключах 🔑

При проектировании базы данных важно выбрать подходящий способ идентификации записей в таблицах. Простой (одиночный) первичный ключ используется чаще всего, но иногда возникает необходимость использовать составной первичный ключ, состоящий из нескольких полей. Рассмотрим случаи, когда это целесообразно сделать.

Есть понятие «Естественная идентификация». Например, каждая книга однозначно идентифицируется по своему ISBN-коду. Но есть сущности, которые не имеют своей собственной идентификации. Например, таблицы со связями. То есть если таблица характеризует какую-то связь между сущностями, то в ней может не быть первичного ключа вообще.

🔐 А что про составной ключ?

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

📌 Пример:
Регистрация сотрудников на курсы повышения квалификации (employee_courses), где один сотрудник не может дважды записаться на один и тот же курс в одно и то же время (employee_id, course_id, start_date).

🗑 Когда избегать составного ключа

🗳 Дублирование значений
Каждый раз, когда добавляем новую запись, приходится повторять одни и те же значения. Это увеличивает объем данных и снижает эффективность хранения.

🗳 Сложность поддержки
Добавление новых строк становится сложнее, так как нужно следить за соответствием всех частей ключа.

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


Как считаете, в нашей задаче есть сущности, для которых подойдет составной первичный ключ?

🩷 Отвлекусь всего лишь на мгновение...

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

Вы знаете, что недавно выступила на конференции ЛАФ. Для многих это событие проходит незаметно, но для меня оно стало особенным — моим первым опытом выступления офлайн перед настоящими профессионалами своего дела. Это было непросто: надо было учесть разные уровни подготовки аудитории, объяснить сложные вещи простым языком, дополнить всё живым примером и укладываться строго в отведённое время. Ведь профессионалы — самые требовательные судьи.

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

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

Огромная благодарность моему супер-куратору Саше и ПСБ Банку, благодаря которым я смогла реализовать свою идею!

Теперь я уверена, что мы можем достичь большего вместе! Спасибо каждому из вас за поддержку и доверие!

📜 Физическая модель данных 📜
На данном этапе разрабатывается физическая структура базы данных, учитывающая особенности выбранной СУБД. Определяются типы полей, индексы, ограничения целостности, триггеры и другие элементы физической структуры.

Структура

🪧Книги
Обратите внимание на типы данных title ISBN. в чем разница?
Название книги - поле переменной длины. ISBN - фиксированной длины. Если символов меньше 13, они заполняются пробелами

Books (
  id INT PRIMARY KEY AUTO_INCREMENT,
  title VARCHAR(255),
  isbn CHAR(13),
  publicationyear YEAR,
  pagescount INT,
  availabilitystatus ENUM('Available', 'Borrowed', ‘Borrowed_here’),
  location VARCHAR(255)
)   

🪧 Соединение автора и книги
Таблица состоит полностью из внешних ключей

BookAuthors (
  book_id INT,
  author_id INT,
  FOREIGN KEY (book_id) REFERENCES Books(id),
  FOREIGN KEY (author_id) REFERENCES Authors(id)
)

🪧 Соединение жанра и книги

BookGenres (
  book_id INT NOT NULL,
  genre_id INT NOT NULL,
  PRIMARY KEY(book_id, genre_id),
  FOREIGN KEY (book_id) REFERENCES Books(id),
  FOREIGN KEY (genre_id) REFERENCES Genres(id)
)

🪧 Авторы

Authors (
  id INT PRIMARY KEY AUTO_INCREMENT,
  fullname VARCHAR(255),
  biography TEXT
)

🪧 Жанры книг

Genres (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255)
)

🪧 Отдел хранения книг

Departments (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(255)
)

Клиенты

Clients (
  id INT PRIMARY KEY AUTO_INCREMENT,
  firstname VARCHAR(255),
  lastname VARCHAR(255),
  readerticketnumber VARCHAR(255),
  phonenumber VARCHAR(255),
  email VARCHAR(255),
  address TEXT
)

🪧Выдача книг
А вот и составной первичный ключ. У записи не делаем свой идентификатор, а делаем первичный ключ из книги и даты выдачи. Одну книгу нельзя выдать 2 раза в один момент. Однозначная идентификация книги обеспечена

Loans (
  book_id INT,
  issuedate DATE,
  user_id INT,
  returndate DATE,
  actualreturndate DATE NULLABLE,
  loantype ENUM('ReadingRoom', 'HomeLoan'),
  PRIMARY KEY(book_id, issuedate),
  FOREIGN KEY (book_id) REFERENCES Books(id),
  FOREIGN KEY (user_id) REFERENCES Users(id)
)

🪧 Штрафы

Fines (
  id INT PRIMARY KEY AUTO_INCREMENT,
  loan_id INT,
  amount DECIMAL(10,2),
  reason TEXT,
  status ENUM('Paid', 'Unpaid'),
  FOREIGN KEY (loan_id) REFERENCES Loans(id)
)

🧮 Индексация 🧮
Следующим пунктом в нашем списке по физическому проектированию идет индексация. Для начала разберемся с этим понятием.

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

🖍Когда нужна индексация?

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

📥 Частые запросы
Если часто выполняются запросы на чтение данных (например, SELECT-запросы), особенно если они фильтруют большие объемы данных.

📥 Запросы с условиями
Запросы, содержащие условия WHERE, ORDER BY, GROUP BY и JOIN, значительно ускоряются благодаря наличию соответствующих индексов.
📥 Операции чтения важнее операций записи
Индексы замедляют операции вставки, обновления и удаления данных, поскольку каждый раз нужно обновлять сами индексы. Поэтому индексация выгодна там, где преобладают операции чтения над операциями изменения данных.

🔎 Какие бывают индексы?

Существует несколько типов индексов, каждый из которых оптимизирован под разные сценарии использования

🔗 B-Tree (B-дерево)

Самый распространенный вид индекса. Используется в большинстве реляционных СУБД (PostgreSQL, MySQL, SQLite). B-Tree позволяет эффективно искать значения по диапазону, сортировать и объединять таблицы.

Преимущества
Эффективная поддержка операторов сравнения (<, >, =).
Позволяет сортировку результатов по заданному полю.
Недостатки
Больший объем памяти для хранения больших объемов данных.


🔗 Hash-индексы

Hash-индексы используются, когда важно исключительно точное совпадение значений (оператор равенства "="). Они быстрее работают с поиском конкретного значения, но не поддерживают диапазон запросов или сортировки.

Преимущества
Очень быстрый доступ по ключу (равенство).
Недостатки
Невозможность эффективного использования с операторами "<", ">", BETWEEN и подобными.


🔗 Bitmap-индексы

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

Преимущества
Компактность и высокая производительность для низкоселективных полей.
Недостатки
Медленно работает с высокоселективными данными.


🔗 Full-text-индексы

Предназначены для полнотекстового поиска, позволяют выполнять поиск по содержимому текста (частей документов, статей и т.п.). Часто применяются в информационных порталах, блогах, поисковиках.

Преимущества
Поддержка сложных операций поиска по словам и фразам.
Недостатки
Сложнее поддерживать и занимают больше места.





❓Как принимать решение о необходимости индексирования?

*️⃣ Типичные запросы
Проведите профилирование ваших приложений и проанализируйте наиболее частые типы запросов. Индексировать имеет смысл именно те поля, которые участвуют в условиях WHERE, ORDER BY, GROUP BY и JOIN.


*️⃣ Анализ производительности
Используйте инструменты анализа запросов вашей базы данных (EXPLAIN ANALYZE в PostgreSQL, EXPLAIN в MySQL и др.) для оценки эффективности существующих планов выполнения запросов. Если запрос долго выполняется, возможно, дело в отсутствии нужного индекса.


*️⃣ Объем данных
Чем больше таблица, тем сильнее ощущается эффект от добавления индекса. Для небольших таблиц индексирование может оказаться избыточным и неоптимальным решением.


*️⃣ Частота изменений
Если ваши данные часто меняются (INSERT/UPDATE/DELETE), убедитесь, что выгода от индекса превышает затраты на обновление самого индекса.


Критерии выбора типа индекса
Важно правильно выбрать тип индекса исходя из особенностей вашего приложения и структуры данных. Например, если важна скорость точного поиска, выбирайте hash-индекс, если важны диапазонные запросы — b-tree, если нужны быстрые операции по низким селективностям — bitmap.