Сравни подходы для доступа к базе данных из прикладного кода и объясни, когда какой подход выбрать.

Подходы доступа к БД из кода: сырой SQL (полный контроль), query builder (программный SQL), ORM (объекты вместо SQL). Выбор — по сложности запросов, скорости разработки и производительности.

Подходы

Сырой SQL

Писать SQL-запросы напрямую:

db.query('SELECT * FROM users WHERE id = $1', [id]);

• Плюсы: полный контроль, максимальная производительность, любые сложные запросы.
• Минусы: ручное маппинг, риск SQL-инъекций (нужны параметры), больше кода, привязка к диалекту БД.
• Когда: сложные оптимизированные запросы, аналитика.

Query Builder

Программное построение SQL (Knex, Kysely):

db('users').where('id', id).select('*');

• Плюсы: типобезопасность, защита от инъекций, гибкость, ближе к SQL.
• Минусы: всё ещё думаешь в терминах SQL.
• Когда: нужен контроль над запросами + удобство.

ORM (Object-Relational Mapping)

Работа с объектами вместо SQL (Prisma, TypeORM, Sequelize):

prisma.user.findUnique({ where: { id }, include: { posts: true } });

• Плюсы: быстрая разработка, типобезопасность, миграции, связи, защита от инъекций.
• Минусы: абстракция скрывает SQL, риск неэффективных запросов (N+1), сложные запросы неудобны.
• Когда: типовой CRUD, быстрая разработка.

Как выбирать

• Типовой CRUD, скорость → ORM.
• Контроль + удобство → query builder.
• Сложные оптимизированные запросы, аналитика → сырой SQL.
• Часто комбинируют: ORM для CRUD, сырой SQL для сложных мест.

Коротко для собеседования

Доступ к БД: сырой SQL (полный контроль, производительность, но ручной маппинг и риск инъекций — для сложных запросов), query builder (программный SQL, типобезопасность — контроль + удобство), ORM (объекты вместо SQL, быстрый CRUD, миграции, но риск N+1 — типовые операции). Выбор по сложности; часто комбинируют ORM + сырой SQL.