вопросы.
1. В базу данных SQL в любом случае уходят запросы select, update, set, remove. В какой последовательности обрабатываются условия where, order, having, union, join, context table expression это решать для SQL. Например, PostgreSQL, сам определяет как выполнить запрос, в зависимости от индексов, структуры и т.д. Если написание sql вызывает фрустрацию, имеет смысл использовать query builder, такой как knexjs (JavaScript). Здесь также присутствует инструмент автозаполнение. И это не чистые строки, которые могут водвергнуться sql injection.
2. Призма все еще остается ORM и сравнение идет с другими ORM со всеми плюсами и минусами. Почему бы не поговорить о минусах первого? Минусы занимают бОльшое количество времени в работе. Как обычно любой уровень абстракции, в том числе ORM, это путь изучения. Рост профессиональных навыков и фич, которые можно реализовать в умеренное время, будет прямо пропорционален возможностям ORM, т.е. чего не умеет ORM или нестандартно для него, потребует резкого выхода из зоны комфорта, как следствие времени для реализации бизнес требования. Например, этот типичный и в тоже время необычный по своему запрос.
select SUM(case when seen_at is null then 1 else 0 end) from "app"."events"
left join app.events_users
on events_users.id = (
select id from app.events_users
where user_id = "5a674f1c-ct5e-11e8-9kb2-03d840d1e489" and event_id = events.id
limit 1
)
where ((
array[1]::integer[] <@ cities
or ARRAY(select country_id from app._cities where city_id = 1) <@ countries
)
and approved = true and archived_at is null
and coalesce(start_time, CURRENT_TIMESTAMP) <= CURRENT_TIMESTAMP
and CURRENT_TIMESTAMP <= coalesce(end_time, CURRENT_TIMESTAMP)
) limit 1
это еще и двухуровневая орм. то есть про контроль над системой можно забыть вообще
Обсуждают сегодня