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

Проектирование баз данных на проекте: опыт и практика

Это хороший поведенческий вопрос, который рассказывает о коллаборации в команде, архитектурных решениях и моей роли в разработке. Позвольте рассказать о моём опыте проектирования БД на production проектах.

Мой опыт с проектированием БД

Обычно в команде это совместная работа:

1. Database Architect/DBA (если есть в команде)

• Проектирует общую схему
• Выбирает БД (PostgreSQL, MySQL, MongoDB)
• Оптимизирует производительность
• Настраивает репликацию и backup

2. Backend разработчик (мой уровень ответственности)

• Проектирую domain модели на основе требований
• Создаю таблицы для сущностей
• Проектирую связи (relationships)
• Пишу миграции (Flyway, Liquibase, Goose)
• Оптимизирую запросы и индексы

3. Product Manager / Business Analyst

• Определяет требования к данным
• Примеры: какие параметры хранить, какую историю

Пример проекта, где я проектировал БД

Возьму real example — e-commerce платформу:

-- Основные сущности (domain entities)
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) UNIQUE NOT NULL,
    password_hash VARCHAR(255) NOT NULL,
    first_name VARCHAR(100),
    last_name VARCHAR(100),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW(),
    deleted_at TIMESTAMPTZ -- soft delete
);

CREATE TABLE products (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    sku VARCHAR(50) UNIQUE NOT NULL,
    name VARCHAR(255) NOT NULL,
    description TEXT,
    price DECIMAL(10, 2) NOT NULL,
    stock_quantity INTEGER NOT NULL DEFAULT 0,
    category_id UUID NOT NULL REFERENCES categories(id),
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

-- Заказы и позиции
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id),
    status VARCHAR(50) NOT NULL DEFAULT 'pending', -- NEW, PAID, SHIPPED, DELIVERED
    total_amount DECIMAL(12, 2) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW(),
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

CREATE TABLE order_items (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    order_id UUID NOT NULL REFERENCES orders(id) ON DELETE CASCADE,
    product_id UUID NOT NULL REFERENCES products(id),
    quantity INTEGER NOT NULL CHECK (quantity > 0),
    unit_price DECIMAL(10, 2) NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- Индексы для оптимизации (очень важно!)
CREATE INDEX idx_orders_user_id ON orders(user_id);
CREATE INDEX idx_orders_status ON orders(status);
CREATE INDEX idx_products_category_id ON products(category_id);
CREATE INDEX idx_order_items_product_id ON order_items(product_id);

Мой процесс проектирования БД

Шаг 1: Анализ требований

1. Какие сущности нужны?
2. Какие relationships между ними?
3. Какие операции? (read/write ratio)
4. Какой объём данных? (scaling)
5. Какие compliance требования? (GDPR, PCI)

Шаг 2: Проектирование модели (ER-диаграмма)

User 1 ─── * Orders
Order 1 ─── * OrderItems
Product * ─── * Categories

Шаг 3: Нормализация (Normalization)

// ❌ Плохо: денормализованная БД
CREATE TABLE orders (
    id UUID,
    user_name VARCHAR(255),  // Дублирование!
    user_email VARCHAR(255),  // Дублирование!
    product_names TEXT,       // Дублирование!
    product_prices TEXT       // Дублирование!
);
// Проблемы: UPDATE аномалии, нарушение ACID

// ✅ Правильно: нормализованная (3NF)
CREATE TABLE users (id, name, email);
CREATE TABLE orders (id, user_id FK, ...);
CREATE TABLE order_items (id, order_id FK, product_id FK, ...);
CREATE TABLE products (id, name, price, ...);

Шаг 4: Выбор типов данных

-- ✅ Правильно выбранные типы
CREATE TABLE accounts (
    id UUID PRIMARY KEY,
    balance DECIMAL(19,4),      -- Для денег, не FLOAT!
    created_at TIMESTAMPTZ,     -- Для времени с timezone
    is_verified BOOLEAN,        -- Для флагов
    metadata JSONB,             -- Для гибких данных
    tags TEXT[]                 -- Для массивов
);

-- ❌ Частые ошибки
balance FLOAT,          -- НИКОГДА для денег!
scores DECIMAL(4,4),    -- Неправильный размер
created_at TIMESTAMP,   -- Без timezone

Шаг 5: Индексирование

public class IndexingStrategy {
    
    // ✅ Индексы для частых запросов
    /*
    SELECT * FROM users WHERE email = ?  -- нужен индекс
    CREATE INDEX idx_users_email ON users(email);
    
    SELECT * FROM orders WHERE user_id = ? AND status = ?
    CREATE INDEX idx_orders_user_status ON orders(user_id, status);
    
    SELECT * FROM products WHERE category_id = ? ORDER BY price DESC
    CREATE INDEX idx_products_cat_price ON products(category_id, price DESC);
    */
    
    // ❌ Лишние индексы замедляют writes
    // Не создавай индекс "на будущее"
}

Реальный пример: проектирование для микросервисной архитектуры

-- User Service DB
CREATE TABLE users (
    id UUID PRIMARY KEY,
    email VARCHAR(255) UNIQUE,
    password_hash VARCHAR(255),
    profile_data JSONB,  -- Гибкие данные профиля
    created_at TIMESTAMPTZ
);

-- Order Service DB (отдельная БД!)
CREATE TABLE orders (
    id UUID PRIMARY KEY,
    user_id UUID NOT NULL,  -- Ссылка на другой сервис (НЕ foreign key!)
    status VARCHAR(50),
    total_amount DECIMAL(12, 2),
    created_at TIMESTAMPTZ
);

-- ⚠️ Важно: НИКОГДА не делаем FK между микросервисами!
-- Используем eventual consistency и компенсирующие транзакции

Миграции: мой процесс работы с версионированием

-- migrations/001_initial_schema.sql
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    email VARCHAR(255) UNIQUE NOT NULL,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- migrations/002_add_user_fields.sql
ALTER TABLE users ADD COLUMN first_name VARCHAR(100);
ALTER TABLE users ADD COLUMN last_name VARCHAR(100);
ALTER TABLE users ADD COLUMN bio TEXT;
CREATE INDEX idx_users_email ON users(email);

-- migrations/003_create_orders_table.sql
CREATE TABLE orders (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    status VARCHAR(50) NOT NULL DEFAULT 'pending',
    created_at TIMESTAMPTZ DEFAULT NOW()
);

Производительность: мой опыт оптимизации

public class QueryOptimization {
    
    // ❌ Плохо: N+1 проблема
    List<Order> orders = orderRepository.findAll();
    for (Order order : orders) {
        User user = userRepository.findById(order.getUserId());  // N запросов!
    }
    
    // ✅ Правильно: JOIN
    List<Order> orders = entityManager.createQuery(
        "SELECT o FROM Order o JOIN FETCH o.user",
        Order.class).getResultList();  // 1 запрос!
    
    // ✅ Правильно: Batch queries
    @Query(value = "SELECT * FROM orders WHERE user_id IN (:userIds)",
           nativeQuery = true)
    List<Order> findByUserIds(@Param("userIds") List<UUID> userIds);
}

Backup и High Availability

# Моя конфигурация для production
postgresql:
  replication:
    enabled: true
    standby_servers: 2  # На случай падения primary
  
  backup:
    type: WAL-G  # Write-Ahead Logging
    frequency: every_1_hour
    retention: 30_days  # Хранить 30 дней
  
  monitoring:
    slow_query_log: true
    threshold_ms: 1000  # Логировать запросы > 1s

Наиболее сложное решение, которое я принял

-- Проблема: большие таблицы (100M+ rows)
-- Решение: Partitioning

CREATE TABLE events (
    id UUID,
    user_id UUID,
    event_type VARCHAR(50),
    created_at TIMESTAMPTZ,
    data JSONB
) PARTITION BY RANGE (created_at);

CREATE TABLE events_2024_01 PARTITION OF events
    FOR VALUES FROM ('2024-01-01') TO ('2024-02-01');

CREATE TABLE events_2024_02 PARTITION OF events
    FOR VALUES FROM ('2024-02-01') TO ('2024-03-01');

-- Результат: запросы на 70% быстрее!
SELECT * FROM events WHERE created_at > '2024-02-01';

Заключение: Мой вклад в проектирование БД

Я отвечаю за:

1. ✅ Дизайн таблиц на основе domain entities
2. ✅ Relationships и constraints (FK, UNIQUE, CHECK)
3. ✅ Миграции и версионирование схемы
4. ✅ Индексирование для оптимизации запросов
5. ✅ Оптимизация SQL (N+1, query plans)
6. ✅ Безопасность (SQL injection prevention)
7. ✅ Обработка ошибок и consistency

С поддержкой:

• DevOps/DBA: инфраструктура, backup, scaling
• Product: требования и спецификации
• QA: тестирование миграций и данных

Ключевая философия: БД — это контракт приложения с данными. Плохое проектирование приводит к большим проблемам в production. Инвестирую время в правильный дизайн на старте.