Приходилось ли вам проектировать схемы данных для SQL и NoSQL баз данных?

Да, проектировал схемы как для реляционных (SQL), так и для нереляционных (NoSQL) баз данных.

Для SQL (PostgreSQL/MySQL):

1. Нормализация: Доведение схемы до 3NF для минимизации дублирования и обеспечения целостности.
2. Типы данных: Выбор оптимальных типов (INT, VARCHAR(n), TIMESTAMPTZ, JSONB).
3. Ограничения: Использование PRIMARY KEY, FOREIGN KEY, UNIQUE, CHECK и NOT NULL.
4. Индексы: Создание B-tree индексов для полей в условиях WHERE, JOIN, ORDER BY. Для полнотекстового поиска — GIN индексы.

Пример SQL-схемы:

CREATE TABLE authors (
    id SERIAL PRIMARY KEY,
    name VARCHAR(200) NOT NULL
);

CREATE TABLE books (
    id SERIAL PRIMARY KEY,
    author_id INTEGER NOT NULL REFERENCES authors(id) ON DELETE CASCADE,
    title VARCHAR(500) NOT NULL,
    published_date DATE,
    metadata JSONB -- Использование JSONB для гибких данных
);

CREATE INDEX idx_books_author_id ON books(author_id);
CREATE INDEX idx_books_title ON books(title);

Для NoSQL (MongoDB):

1. Денормализация: Проектирование схемы, ориентированной на паттерны чтения, часто с вложенными документами для уменьшения количества запросов.
2. Embedding vs Referencing: Решение, когда встраивать дочерние документы, а когда ссылаться на отдельные коллекции.
3. Индексы: Создание индексов для полей запросов, включая составные и текстовые индексы.

Пример MongoDB-документа:

{
  "_id": ObjectId("..."),
  "order_id": "ORD-12345",
  "customer": {
    "name": "John Doe",
    "email": "john@example.com"
  },
  "items": [
    { "product_id": 101, "quantity": 2, "price": 29.99 },
    { "product_id": 205, "quantity": 1, "price": 15.50 }
  ],
  "total": 75.48
}