Database Schema Documentation

## Table: users

**Purpose**: Хранит информацию об учетных записях пользователей и данные аутентификации

**Relationships**: 
- Один-ко-многим с `orders` (users.id → orders.user_id)
- Один-ко-многим с `user_sessions` (users.id → user_sessions.user_id)

| Column | Type | Constraints | Default | Description |
|--------|------|-------------|---------|-------------|
| id | BIGINT | PRIMARY KEY, AUTO_INCREMENT | - | Уникальный идентификатор пользователя |
| email | VARCHAR(255) | UNIQUE, NOT NULL | - | Email адрес пользователя (логин) |
| password_hash | VARCHAR(255) | NOT NULL | - | Bcrypt хешированный пароль |
| first_name | VARCHAR(100) | NOT NULL | - | Имя пользователя |
| last_name | VARCHAR(100) | NOT NULL | - | Фамилия пользователя |
| created_at | TIMESTAMP | NOT NULL | CURRENT_TIMESTAMP | Дата создания аккаунта |
| updated_at | TIMESTAMP | NOT NULL | CURRENT_TIMESTAMP ON UPDATE | Дата последней модификации |
| is_active | BOOLEAN | NOT NULL | TRUE | Флаг статуса аккаунта |

**Indexes**:
- `idx_users_email` (email) - Уникальный индекс для запросов логина
- `idx_users_created_at` (created_at) - Для хронологических запросов
- `idx_users_active` (is_active, created_at) - Составной индекс для запросов активных пользователей

**Business Rules**:
- Email должен быть в правильном формате (контролируется приложением)
- Пароль должен быть минимум 8 символов (контролируется приложением)
- Мягкое удаление: установить `is_active = FALSE` вместо физического удаления

## Связи

### users → orders (Один-ко-многим)
- **Foreign Key**: orders.user_id → users.id
- **Constraint**: ON DELETE RESTRICT (предотвращает удаление пользователей с заказами)
- **Cardinality**: Один пользователь может иметь ноль или много заказов
- **Business Rule**: Все заказы должны принадлежать действительной учетной записи пользователя

### orders → order_items (Один-ко-многим)
- **Foreign Key**: order_items.order_id → orders.id
- **Constraint**: ON DELETE CASCADE (удаляет элементы при удалении заказа)
- **Cardinality**: Один заказ должен иметь минимум один элемент заказа

## View: customer_order_summary

**Purpose**: Агрегированное представление статистики заказов клиентов для отчетности

**Base Tables**: users, orders, order_items, products

**Definition**:
```sql
CREATE VIEW customer_order_summary AS
SELECT 
    u.id as customer_id,
    u.first_name,
    u.last_name,
    u.email,
    COUNT(o.id) as total_orders,
    SUM(oi.quantity * oi.unit_price) as total_spent,
    MAX(o.created_at) as last_order_date
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
LEFT JOIN order_items oi ON o.id = oi.order_id
WHERE u.is_active = TRUE
GROUP BY u.id, u.first_name, u.last_name, u.email;

**Общие типы PostgreSQL**:
- `UUID` - Для глобально уникальных идентификаторов
- `JSONB` - Для структурированных данных документов
- `ARRAY` - Для данных типа список
- `ENUM` - Для предопределенных наборов значений
- `TIMESTAMP WITH TIME ZONE` - Для дат с учетом часовых поясов

**Пример использования ENUM**:
```sql
CREATE TYPE order_status AS ENUM ('pending', 'confirmed', 'shipped', 'delivered', 'cancelled');

CREATE TABLE orders (
    id BIGSERIAL PRIMARY KEY,
    status order_status NOT NULL DEFAULT 'pending',
    -- other columns...
);

## Документация схем NoSQL

### Пример коллекции MongoDB
```markdown
## Collection: products

**Purpose**: Каталог продуктов с информацией о вариантах и инвентаре

**Document Structure**:
```json
{
  "_id": "ObjectId",
  "sku": "string (required, unique)",
  "name": "string (required)",
  "description": "string",
  "category": {
    "id": "ObjectId",
    "name": "string",
    "path": "string" // e.g., "Electronics/Computers/Laptops"
  },
  "variants": [
    {
      "id": "ObjectId",
      "attributes": {
        "color": "string",
        "size": "string"
      },
      "price": "number (decimal)",
      "inventory_count": "number (integer)"
    }
  ],
  "tags": ["string"],
  "created_at": "Date",
  "updated_at": "Date",
  "is_active": "boolean"
}

## Migration: 2024_01_15_add_user_preferences

**Version**: 1.2.3
**Date**: 2024-01-15
**Author**: John Doe
**Ticket**: PROJ-1234

**Changes**:
- Добавлена таблица `user_preferences` для хранения пользовательских настроек
- Добавлено ограничение внешнего ключа от user_preferences к users
- Добавлен индекс на user_preferences.user_id

**Migration Script**:
```sql
CREATE TABLE user_preferences (
    id BIGINT AUTO_INCREMENT PRIMARY KEY,
    user_id BIGINT NOT NULL,
    preference_key VARCHAR(100) NOT NULL,
    preference_value TEXT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES users(id) ON DELETE CASCADE,
    UNIQUE KEY unique_user_preference (user_id, preference_key)
);

CREATE INDEX idx_user_preferences_user_id ON user_preferences(user_id);