SQL и БД | Базы данных

SQL Типы данных в БД. Влияние на производительность.

Основная ошибка при выборе типа данных — выбирать на всякий случай побольше

Примеры антипаттернов:
⛔VARCHAR(255) для всего подряд, даже если код строки состоит из 5 символов
⛔TEXT для email-адресов
⛔BEGINT для счетчика, где максимум 100 записей
⛔FLOAT для денег (потеря точности)

Как правильно
✅Размер строки выбирать под задачу
✅VARCHAR(50) - для email
✅CHAR(2) - для код страны
✅NUMERIC(10, 2) или DECIMAL - для денег
✅BOOLEAN - для булевых значений
✅DATE или TIMESTAMP - для даты

🔥При правильно подобранных типах меньше багов, больше свободного места и быстре выполняются запросы

Оператор between в SQL

Оператор BETWEEN в SQL проверяет, попадает ли значение столбца в указанный диапазон, причём обе границы включаются. Он делает код более читаемым, заменяя пару сравнений (>= и <=) одним удобным условием. 

Синтаксис:
WHERE col1 BETWEEN 5 AND 10

Это эквивалентно:
WHERE col1 >= 5 AND col1 <= 10

⚠Оператор BETWEEN является включающим, то есть включает граничные значения в результаты

ORDER BY
Оператор ORDER BY в SQL используется для сортировки строк в результате запроса и позволяет явно задать, как упорядочить данные.

⚠По умолчанию сортировка выполняется по возрастанию:

SELECT *
FROM table_name
ORDER BY column_name

Чтобы указать направление сортировки, добавьте ASC (по возрастанию) или DESC (по убыванию):

ORDER BY column_name DESC
ORDER BY column_name ASC

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

SELECT *
FROM competition
ORDER BY age DESC, speed DESC

Советы по проектированию БД
Проектирование SQL-базы данных — это баланс между нормализацией (для минимизации избыточности) и практичностью (для скорости чтения). 

Концептуальная модель
Прежде чем писать SQL, нарисуйте ERD (диаграмму «сущность-связь»). Это помогает наглядно увидеть связи между данными, обсудить требования с командой или заказчиком и избежать ошибок на раннем этапе. 

Принцип нормализации
Разделяйте данные на логические сущности (например, отдельно «Пользователи», «Товары», «Заказы») и избегайте дублирования информации. Это снижает избыточность, упрощает обновления и уменьшает риск ошибок.

Используйте первичные и внешние ключи
Первичный ключ однозначно идентифицирует запись в таблице. Внешние ключи устанавливают связи между таблицами, обеспечивая целостность данных. Не пренебрегайте опциями ON DELETE и ON UPDATE (например, CASCADE, SET NULL) — они определяют, что произойдёт с зависимыми записями при изменении или удалении родительской. 

Используйте подходящие типы данных
Выбирайте типы данных осознанно. Не используйте NVARCHAR(MAX) или TEXT без крайней необходимости — это может занимать больше места и замедлять операции. Для числовых значений используйте DECIMAL или INT, для дат — DATE. Для уникальных идентификаторов (например, в связке с внешними ключами) часто удобны суррогатные ключи (INT IDENTITY), а не составные. 

Оптимизируйте индексы
Индексы ускоряют выполнение запросов, но их нужно применять разумно. Создавайте индексы на столбцах, которые часто используются в условиях WHERE, при сортировках или в предложениях JOIN. Однако не переусердствуйте: каждый индекс замедляет операции вставки и обновления. Избегайте индексации столбцов с очень малым количеством уникальных значений (например, «Пол»).

Применяйте ограничения для качества данных
Используйте NOT NULL для полей, которые обязаны иметь значение. Для проверки допустимости значений (например, чтобы цена была положительной) применяйте CHECK. Это встроенная защита от некорректных данных. 

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

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

Специфика проекта
Не существует универсального рецепта — оптимальная структура зависит от требований, объёма данных и нагрузки. Например, для аналитической базы данных (OLAP) денормализация может быть оправдана, но для оперативной обработки транзакций (OLTP) она часто снижает производительность. 

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