Зачем нужны схемы в БД?

# Зачем нужны схемы в БД

Схема базы данных (database schema) — это структурное описание того, как организованы данные: какие таблицы существуют, какие колонки в каждой таблице, какие типы данных они содержат, какие ограничения и отношения между ними.

Схема как чертёж

Аналогия: если база данных — это дом, то схема — это его архитектурный чертёж:

Чертёж (Schema):
┌─────────────────────────────────┐
│ USERS таблица                   │
├─────────────────────────────────┤
│ id: INTEGER PRIMARY KEY         │
│ name: VARCHAR(255)              │
│ email: VARCHAR(255) UNIQUE      │
│ created_at: TIMESTAMP           │
└─────────────────────────────────┘

Дом (База данных):
TABLE users {
  1, 'Alice', 'alice@example.com', '2024-01-01'
  2, 'Bob', 'bob@example.com', '2024-01-02'
  ...
}

Основные функции схемы

1. Определение структуры данных

Схема описывает, как должны выглядеть данные:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    email VARCHAR(255) UNIQUE NOT NULL,
    age INTEGER CHECK (age >= 0),
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

Это говорит:

• У каждого пользователя есть id (уникальный, автоинкремент)
• name обязателен (NOT NULL)
• email уникален и обязателен
• age не может быть отрицательным
• created_at автоматически заполняется текущим временем

2. Обеспечение целостности данных

Схема гарантирует, что данные логически консистентны:

-- Таблица постов
CREATE TABLE posts (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id),
    title VARCHAR(255) NOT NULL,
    content TEXT
);

-- Внешний ключ (FOREIGN KEY) гарантирует:
-- - Пост может принадлежать только существующему пользователю
-- - Если удалить пользователя — можно автоматически удалить его посты

# Попытка вставить данные нарушающие схему
# ОШИБКА: user_id 999 не существует!
db.execute(
    "INSERT INTO posts (user_id, title) VALUES (999, 'Title')"
)
# PostgreSQL: ERROR: insert or update on table "posts" violates 
# foreign key constraint "posts_user_id_fkey"

3. Типизация данных

Схема определяет, какие типы данных хранятся:

CREATE TABLE products (
    id SERIAL,
    name VARCHAR(255),        -- Текст
    price DECIMAL(10, 2),     -- 10 цифр, 2 после запятой
    stock INTEGER,            -- Целое число
    created_at TIMESTAMP,     -- Дата и время
    is_active BOOLEAN         -- Логический тип
);

Попытка вставить неправильный тип:

# ОШИБКА: 'abc' не число!
db.execute(
    "INSERT INTO products (price) VALUES ('abc')"
)
# PostgreSQL: ERROR: invalid input syntax for type numeric

4. Оптимизация запросов

Схема позволяет базе данных оптимизировать запросы:

-- Если знаем, что email уникален (UNIQUE), можно быстро найти пользователя
CREATE INDEX idx_users_email ON users(email);

-- Теперь этот запрос выполняется мгновенно
SELECT * FROM users WHERE email = 'alice@example.com';

5. Безопасность

Схема защищает от ошибок и некорректных данных:

CREATE TABLE accounts (
    id SERIAL PRIMARY KEY,
    balance DECIMAL(15, 2) CHECK (balance >= 0),  -- Баланс не может быть отрицательным
    user_id INTEGER NOT NULL UNIQUE REFERENCES users(id)
);

-- Попытка создать аккаунт с отрицательным балансом
INSERT INTO accounts (user_id, balance) VALUES (1, -100);
-- ERROR: new row for relation "accounts" violates check constraint

Пример: e-commerce приложение

-- Пользователи
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    name VARCHAR(255) NOT NULL,
    created_at TIMESTAMP DEFAULT NOW()
);

-- Товары
CREATE TABLE products (
    id SERIAL PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    price DECIMAL(10, 2) NOT NULL CHECK (price > 0),
    stock INTEGER NOT NULL CHECK (stock >= 0)
);

-- Заказы
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id INTEGER NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    created_at TIMESTAMP DEFAULT NOW(),
    total_amount DECIMAL(15, 2) NOT NULL
);

-- Позиции в заказе
CREATE TABLE order_items (
    id SERIAL PRIMARY KEY,
    order_id INTEGER NOT NULL REFERENCES orders(id) ON DELETE CASCADE,
    product_id INTEGER NOT NULL REFERENCES products(id),
    quantity INTEGER NOT NULL CHECK (quantity > 0),
    price_at_purchase DECIMAL(10, 2) NOT NULL
);

Эта схема гарантирует:

• Каждый заказ принадлежит реальному пользователю
• Каждый товар в заказе существует в каталоге
• Цены положительные, количества положительные
• При удалении пользователя его заказы тоже удаляются

Как база данных проверяет схему

# Когда вы выполняете запрос:
db.execute("INSERT INTO users (email, name) VALUES ('alice@example.com', 'Alice')")

# База данных:
# 1. Проверяет, существует ли таблица users ✓
# 2. Проверяет, существуют ли колонки email и name ✓
# 3. Проверяет типы: email VARCHAR? name VARCHAR? ✓
# 4. Проверяет constraints: email UNIQUE? (нет дубликатов?) ✓
# 5. Проверяет NOT NULL: есть значения? ✓
# 6. Если всё ОК, вставляет данные ✓

Миграции и эволюция схемы

Схема может меняться со временем. Это делается через миграции:

-- Migration 001_initial.sql
CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL
);

-- Migration 002_add_phone.sql
ALTER TABLE users ADD COLUMN phone VARCHAR(20);

-- Migration 003_add_index.sql
CREATE INDEX idx_users_phone ON users(phone);

В Python с Alembic/Goose:

# migrations/001_initial.py
def up():
    execute("""
    CREATE TABLE users (
        id SERIAL PRIMARY KEY,
        email VARCHAR(255) UNIQUE NOT NULL
    )
    """)

def down():
    execute("DROP TABLE users")

Без схемы: что может пойти не так

# Если БД без схемы (как JSON файл или NoSQL без валидации)

users = [
    {'id': 1, 'name': 'Alice', 'email': 'alice@example.com'},
    {'id': 2, 'name': 'Bob'},  # ❌ Нет email!
    {'id': 3, 'name': 'Charlie', 'email': 123},  # ❌ email — число!
    {'id': '4', 'name': 'David', 'email': 'david@example.com'},  # ❌ id — строка!
    {'id': 1, 'name': 'Eve', 'email': 'eve@example.com'},  # ❌ Дубликат id!
]

# Код должен проверять все эти случаи вручную
# Много ошибок, медленнее, сложнее поддерживать

Заключение

Схема базы данных — это контракт между приложением и данными:

✅ Обеспечивает целостность — данные логически консистентны ✅ Типизирует данные — каждое значение правильного типа ✅ Защищает от ошибок — невозможно вставить неправильные данные ✅ Оптимизирует производительность — БД может строить индексы и optimizing queries ✅ Документирует структуру — новый разработчик сразу видит, как организованы данные ✅ Облегчает поддержку — миграции позволяют безопасно менять структуру

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