Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Все поля (даже одного типа данных) не всегда нужны. И поэтому либо функция на каждую проекцию, либо тормоза.

Их можно как-инбудь передать в функцию. Ты же тоже их по сути явно передаешь через свой `select`.

EP>А зачем вручную денормализовать когда есть materialized view?

Это просто пример. Materialized views кстати далеко не всегда можно использовать. Например БД может их тупо не уметь делать (постгрес например).

EP>Не буду, это пример на декомпозицию. Я уже выше показывал:
EP>

EP>>Можно часто используемый запрос в отдельную функцию:
EP>>

EP>>auto recent_customers()
EP>>{
EP>>    return from(customers) ...;
EP>>}
EP>>...
EP>>{
EP>>    auto q = from(recent_customers).join(...).where(...).select(...);
EP>>    // ...
EP>>}
EP>>

EP>Вот только эту функцию (recent_customers) и придётся менять.
EP>А в случае DAL и простых строковых запросов у тебя внутри DAL нужно будет менять много мест, так как нет нормальных средств декомпозиции.

Если они не в compile-time это не значит что они плохие. Кстати, как ты планируешь гарантировать существование нужных таблиц и полей в БД? Тот случай когда в коде все ок и все компилируется, но схема изменилась. КМК из constexpr к БД никак не подключиться

EP>Нет, я говорю что легче рефакторить код, имея типизацию. Обновил схему в коде из БД — все ошибки вылезли во время компиляции.

Ну можно ведь не рефактроирть. Не обязательно приложению заранее знать какие там у объекта поля в БД есть. Если это какой-нибудь веб сервис — очень часто его можно написать так, чтобы он ничего такого не знал заранее и динамически загружал схему (и даже изменения на лету подхватывал). Мне, в моей практике, обычно что-то подобное попадается. А вот в таком стиле как ты хочешь реализовать, тоже, но обычно это более простые приложения.