Здравствуйте, chaotic-kotik, Вы писали:

EP>>Так а как ты предлагаешь делать? На каждый вариант проекции делать отдельную функцию в DAL? Постоянно модифицировать API DAL при необходимости нового поля?
CK>Отдельную ф-ю на каждый вариант проектции делать не нужно, ее нужно делать на каждый поддерживаемый тип данных,

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

EP>>Так а в чём профит?
EP>>Почему не должен знать? Зачем вводить новые слои на ровном месте? То есть что это даст по факту? И реально ли это необходимо?
CK>Простой пример, приложение работающее с каталогом — есть две таблицы, которые обозначают модель мобильного телефона и конкретное устройство, скажем iPhone 6s и 64х гигабайтная версия iPhone 6s. Пользователю показывают в каталоге продуктов iPhone 6s, когда он по нему кликает — показывают список устройств с разным объемом памяти и размером экрана. Чтобы показать все параметры нужно сделать join двух таблиц. Мы попрофилировали и поняли, что джоин съедает дофига, нужно денормализовать эти две таблицы сделав одну.

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

CK>Теперь мы можем одним select-ом выбрать iPhone 6s 64GB устройство или iPhone 6s модель телефона и там будут все нужные данные.
CK>Теперь я пойду в код и поменяю один файл с кодом в своем dal, а ты будешь искать в коде все функции, использующие эти таблицы.

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

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>

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

EP>>За счёт типизации как раз проводить рефакторинги намного проще. Ошибки отлавливаются на этапе компиляции. В случае с текстовыми запросами точно также придётся проводить рефакторинги, только уже без помощи типизации.
CK>Ты предлагаешь парадоксальную вещь — рефакторить схему БД в коде. Изменили имя поля — рефакторить?

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

CK>Суть БД в том, что приложению класть на layout данных в БД, для этого есть SQL.

БД абстрагирует от физического layout и прочего, но не от схемы. При изменении схемы, код придётся менять и в моём и в твоём варианте. Причём в твоём ещё может придётся менять код промежуточного слоя.