ORM (объектно-реляционное отображение)

ORM (Object-Relational Mapper, объектно-реляционный маппер) — это библиотека, которая переводит данные между таблицами и строками реляционной базы данных и собственными объектами и классами приложения, позволяя разработчику писать `User.where(email: "a@b.com")` или `$user->posts()->where('published', true)->get()` вместо ручного написания SQL-строк для каждого запроса. Почему это важно для разработчиков AI/SaaS-продуктов: ORM (Eloquent в Laravel, Prisma и Drizzle в экосистеме Node/TypeScript, SQLAlchemy в Python, ActiveRecord в Rails) — это то, как подавляющее большинство современных SaaS-бэкендов ежедневно взаимодействует со своей базой данных, поскольку они значительно ускоряют разработку, обеспечивают типобезопасность (особенно Prisma и Drizzle, которые генерируют типы TypeScript напрямую из схемы базы данных) и централизуют миграции схемы. Применительно к AI-функциям те же ORM-модели, что представляют строку `User` или `Document`, обычно несут в себе и колонку `embedding` (через pgvector), а также связи, используемые для объединения структурированных бизнес-данных с результатами векторного поиска в одном месте. Как это работает: ORM сопоставляет каждую таблицу базы данных с классом/моделью, каждую строку — с экземпляром этого класса, а каждый столбец — со свойством, и переводит цепочки методов или синтаксис query builder в реальный SQL, отправляемый в базу данных «под капотом». У этого удобства есть хорошо известный побочный эффект — проблема N+1 запросов: наивный перебор списка объектов с обращением к связанному объекту у каждого (например, блок на Ruby `posts.each { |p| p.author.name }`) запускает по одному запросу на каждую итерацию вместо одного эффективного join или пакетного запроса — незаметно на демо с 10 строками, катастрофично в продакшене с 10 000 строк. Большинство зрелых ORM предоставляют синтаксис для «жадной» (eager) загрузки специально для того, чтобы разработчики могли явно объединять запросы связанных данных и избегать этой ловушки (`.with('author')` в Eloquent, `include` в Prisma). Практический пример: эндпоинт дашборда AI-SaaS для управления проектами перебирает 200 задач и для каждой отдельно запрашивает имя исполнителя — итого 201 обращение к базе данных, и эндпоинт отвечает за 4 секунды. Переписывание запроса с eager loading — `Task::with('assignee')->where('project_id', $id)->get()` — сводит это к 2 запросам (один для задач, один пакетный для всех исполнителей), и тот же эндпоинт отвечает менее чем за 100 мс. Проблему N+1 стоит выделить особо, потому что ORM позволяют случайно написать её в коде, который выглядит абсолютно идиоматично — ничто в `p.author.name` внутри цикла не выглядит как проблема производительности при чтении, именно поэтому команды всё чаще добавляют инструменты автоматического обнаружения N+1 (например, `preventLazyLoading()` в Laravel для непродакшен-окружений), чтобы ловить это на код-ревью, а не полагаться на то, что человек заметит проблему при ручном просмотре кода.