Как часто используешь SQL в работе?

SQL в работе System Analyst: практическое использование

Это хороший вопрос, потому что он показывает, насколько практик System Analyst. SQL важен не только для разработчиков, но и для аналитиков, которые проектируют системы. Вот мой подробный ответ о роли SQL в работе.

Как часто я использую SQL

Я использую SQL примерно 30-40% времени, и это интегрировано в мою повседневную работу. Это не основная задача, но критически важный навык.

Когда я пишу SQL

1. Анализ требований (10-15%)

Понимание текущих данных:

-- При анализе проекта нужно понять структуру БД
SELECT table_name, column_name, data_type 
FROM information_schema.columns 
WHERE table_schema = 'public'
ORDER BY table_name;

Анализ объёмов данных:

-- Сколько пользователей, заказов, логов?
SELECT 
  COUNT(*) as total_users,
  COUNT(CASE WHEN created_at > NOW() - INTERVAL '30 days' THEN 1 END) as last_30_days
FROM users;

Изучение relationships:

-- Как связаны таблицы? Какой is foreign key pattern?
SELECT 
  constraint_name, 
  table_name, 
  column_name, 
  referenced_table_name
FROM information_schema.key_column_usage;

2. Проектирование схемы (20-25%)

При проектировании новой сущности:

-- Пишу миграции для создания таблиц
CREATE TABLE orders (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL REFERENCES users(id),
  status VARCHAR(20) NOT NULL DEFAULT 'pending',
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
  
  -- Индексы для частых запросов
  UNIQUE(user_id, id),
  INDEX idx_user_status (user_id, status),
  INDEX idx_created (created_at DESC)
);

Анализ query patterns:

• Как будут читать данные?
• Какие нужны индексы?
• Какая нормализация оптимальна?

Определение хранилища:

Запрос:  "Получить баланс пользователя за последний месяц"
╰→ Нужна денормализованная таблица? Или достаточно JOIN?
╰→ Нужен индекс по user_id и date?
╰→ Это OLTP или OLAP?

3. Решение проблем производительности (10-15%)

Анализ медленных запросов:

-- Найти N+1 проблемы
EXPLAIN ANALYZE
SELECT u.*, o.* 
FROM users u
JOIN orders o ON o.user_id = u.id
WHERE u.id = $1;

Проверка индексов:

-- Какие индексы неиспользуемые?
SELECT * FROM pg_stat_user_indexes 
WHERE idx_scan = 0 
ORDER BY idx_blks_hit DESC;

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

-- Вместо этого (медленно):
SELECT * FROM orders WHERE user_id IN (
  SELECT id FROM users WHERE status = 'active'
);

-- Пишу это (быстрее):
SELECT o.* 
FROM orders o
JOIN users u ON o.user_id = u.id
WHERE u.status = 'active';

4. Дизайн API (5-10%)

Определение pagination:

• Сколько records в одном ответе?
• Как реализовать offset vs cursor?
• Нужна ли сортировка?

Определение фильтров:

-- Если API поддерживает фильтры, нужно понять индексирование
GET /api/v1/orders?user_id=123&status=completed&created_from=2024-01-01

-- Нужна ли составная индекс (user_id, status, created_at)?
INDEX idx_list_orders (user_id, status, created_at DESC);

5. Миграции и versioning (5-10%)

При добавлении новой колонки:

-- Нужно ли это поле в отдельной таблице?
-- Можно ли денормализировать?
-- Как это повлияет на производительность?

ALTER TABLE orders ADD COLUMN total_discount DECIMAL(10, 2);
UPDATE orders SET total_discount = 0;
ALTER TABLE orders ALTER COLUMN total_discount SET NOT NULL;

Архивирование старых данных:

-- Как эффективно архивировать старые логи?
CREATE TABLE audit_logs_2024_q1 AS
SELECT * FROM audit_logs 
WHERE created_at >= '2024-01-01' AND created_at < '2024-04-01';

DELETE FROM audit_logs 
WHERE created_at < '2024-01-01';

Уровень SQL-навыков System Analyst

Базовые (ОБЯЗАТЕЛЬНЫ):

• SELECT, FROM, WHERE, JOIN
• GROUP BY, HAVING, ORDER BY
• INDEX, PRIMARY KEY, FOREIGN KEY
• Понимание EXPLAIN ANALYZE
• Базовая денормализация

Промежуточные (ЖЕЛАТЕЛЬНЫ):

• Window functions (ROW_NUMBER, RANK)
• CTE (WITH queries)
• Transactions и ACID
• Query optimization
• Индексирование стратегии

Продвинутые (NICE-TO-HAVE):

• JSON/JSONB работа
• Partitioning
• Replication и failover
• Sharding стратегии
• Query planning

SQL в разных контекстах

Микросервисная архитектура

"Как разделить данные между микросервисами?"
╰→ Какие таблицы идут в User Service?
╰→ Какие в Order Service?
╰→ Как avoid distributed joins?

Data warehouse

"Как спроектировать schema для аналитики?"
╰→ Star schema vs Snowflake?
╰→ Какие fact tables и dimensions?
╰→ Как агрегировать эффективно?

Масштабирование

"Что делать когда table имеет 1 миллиард rows?"
╰→ Partitioning по дате?
╰→ Архивирование старых данных?
╰→ Шардирование по user_id?

Примеры из практики

Ситуация 1: Выбор OLTP vs OLAP

Бизнес-требование: "Нужны отчеты по продажам за день"

Проблема: Если делать это на production OLTP БД:
- Heavy aggregation queries
- Блокирует обычные операции
- Медленно выполняется

Решение:
- Отдельная Analytical DB (Snowflake, BigQuery)
- Replication из production каждый час
- Там пишем тяжелые аналитические queries

Ситуация 2: Индексирование

Проблема: API "GET /orders?user_id=123&status=completed" медленно

Анализ:
BEFORE:
```sql
INDEX idx_user (user_id)
-- При user_id есть 100k orders, но нужно отфильтровать только completed
Query смотрит все 100k, потом фильтрует → МЕДЛЕННО

Решение:

DROP INDEX idx_user;
CREATE INDEX idx_user_status (user_id, status);  -- Составной индекс
-- Теперь index уже отфильтрован → БЫСТРО

### Ситуация 3: Денормализация

Проблема: Отчет "Заказ с информацией пользователя" требует JOIN

Безопасность vs Производительность: OPTION 1 (Нормализованный):

SELECT o.*, u.name, u.email
FROM orders o
JOIN users u ON o.user_id = u.id;
-- Медленно при 1M orders

OPTION 2 (Денормализованный):

ALTER TABLE orders ADD COLUMN user_name VARCHAR(255);
ALTER TABLE orders ADD COLUMN user_email VARCHAR(255);
-- Быстро, но нужно обновлять при изменении пользователя
TRIGGER на update users → update orders

Решение: Выбрать в зависимости от read vs write ratio

## Когда я НЕ пишу SQL

**ORM делает за меня:**
```python
# SQLAlchemy напишет SQL за разработчика
order = Order.query.filter_by(user_id=123, status='completed').all()

Но я понимаю, какой SQL сгенерируется:

SELECT * FROM orders WHERE user_id = $1 AND status = $2;
-- Есть ли индекс на (user_id, status)?

Best Practices для System Analyst

SQL как инструмент проектирования:

1. Перед выбором БД — пишу примеры запросов
2. При проектировании схемы — проверяю индексирование
3. При создании API — анализирую query patterns
4. При оптимизации — смотрю EXPLAIN ANALYZE

Сотрудничество с разработчиками:

• Не пишу SQL for production (разработчик это делает)
• Но проверяю, что SQL правильный
• Предлагаю индексы и оптимизации
• Объясняю trade-offs

Документирование:

"Как устроена таблица orders?"

таблица      → orders
Ключ         → id (UUID)
Внешний ключ → user_id (REFERENCES users.id)
Индексы      → idx_user_status (user_id, status, created_at DESC)
Данные       → ~10M rows
Grouth       → +100k/день
Историзация  → soft delete (deleted_at)

Заключение

SQL для System Analyst — это не столько о написании сложных queries, сколько о понимании данных и их оптимизации.

Использование SQL:

• 30-40% моего времени
• Почти ежедневно
• В контексте проектирования, а не implementation
• Для понимания trade-offs и risks

Уровень владения:

• Intermediate-Advanced
• Достаточно для проектирования любой архитектуры
• Не нужно быть SQL-экспертом

Резюме: Хороший System Analyst должен понимать SQL достаточно хорошо, чтобы проектировать правильные схемы, выбирать оптимальные индексы и предсказать производительность. Не нужно писать сложные queries, но нужно знать, как они работают.