Разрушение мифов о "схемах без схем" и выбор между встраиванием и ссылками. Узнайте, как структурировать данные для максимальной производительности чтения и записи.
Это самое опасное заблуждение в современной разработке. Гибкость схемы (Schema-less) означает, что база данных не принудительно проверяет структуру на уровне SQL-таблиц. Но это не значит, что ваш код должен жить в хаосе.
В JSON Smith мы придерживаемся философии Schema Enforcement. Отсутствие схемы в базе данных переносит ответственность на уровень приложения. Без строгой валидации (например, через JSON Schema или GraphQL) вы получите "болото данных" — неструктурированный массив объектов, который невозможно агрегировать или масштабировать.
Правило №1
Проектируйте схему данных на основе ваших запросов (Query-Driven Design), а не на основе сущностей бизнеса.
Храните данные "один-ко-многим" внутри одного документа.
Плюсы: Чтение за один запрос (O(1)), атомарные обновления.
Минусы: Дублирование данных, риск превышения лимита размера документа (например, 16MB в MongoDB).
Храните только ID и выполняйте join на уровне приложения или через DB-операторы.
Плюсы: Нормализация данных, нет ограничений по размеру.
Минусы: Высокая задержка (N+1 проблема), сложность транзакций.
Рекомендация: Если данные часто запрашиваются вместе — встраивайте. Если дочерний массив бесконечен (например, логи или комментарии) — используйте ссылки.
В реляционных базах мы нормализуем, чтобы избежать аномалий записи. В NoSQL для высоконагруженных систем мы часто идем по пути интенсивной денормализации.
Вместо того чтобы делать JOIN таблиц "Пользователь" и "Профиль", мы храним копию имени пользователя внутри каждого документа "Профиль". Да, это избыточность. Но это снижает время отклика с 150ms до 12ms, так как мы устраняем сетевые вызовы и блокировки дискового ввода-вывода.
Рис 1. Сравнение денормализованного и нормализованного подхода в JSON Smith.
Не угадывайте, как ваши данные будут масштабироваться. Проверьте это в JSON Smith Sandbox.