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

C>Если это критический по времени запрос — ну так и делаем отдельный метод. Какие проблемы? Реально их будут ну максимум десятки штук.
проблемы такие, что получив от клиента запрос на убыстрение запроса, вместо элементарной настройки индекса мы вынуждены будем поставить ему НОВУЮ версию фасада

C>Что в этом плохого?
чем плохо размножение идентичного кода по массе клиентов? Может хотя-бы тем, что их все тестировать надо? Проблемой дублирования кода начали заниматься лет 50 назад уж наверное

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

C>>Если это критический по времени запрос — ну так и делаем отдельный метод. Какие проблемы? Реально их будут ну максимум десятки штук.
S>проблемы такие, что получив от клиента запрос на убыстрение запроса, вместо элементарной настройки индекса мы вынуждены будем поставить ему НОВУЮ версию фасада
Если метод настолько критичен, что поиск по главному ключу вызывает непереносимый оверхед, то это стоит однозначно выделить в отдельный API. Такие контракты должны быть явно прописаны, вместо неявных "а вот если вы запросите только эти 3 поля, то запрос будет в 10 раз быстрее".

C>>Что в этом плохого?
S>чем плохо размножение идентичного кода по массе клиентов? Может хотя-бы тем, что их все тестировать надо? Проблемой дублирования кода начали заниматься лет 50 назад уж наверное
Есть 100500 разных клиентов? Не верю. Максимум 2-3.

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

C>Если метод настолько критичен, что поиск по главному ключу вызывает непереносимый оверхед, то это стоит однозначно выделить в отдельный API. Такие контракты должны быть явно прописаны, вместо неявных "а вот если вы запросите только эти 3 поля, то запрос будет в 10 раз быстрее".
в 10 раз не будет. А вот нагрузочное тестирование сможет провалить, или в продакшене начнет тормозить, попробуй это на стадии спецификации угадать

C>Есть 100500 разных клиентов? Не верю. Максимум 2-3.

серьезно? Их десятки в разных странах, я даже точное число не знаю

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

C>>Если метод настолько критичен, что поиск по главному ключу вызывает непереносимый оверхед, то это стоит однозначно выделить в отдельный API. Такие контракты должны быть явно прописаны, вместо неявных "а вот если вы запросите только эти 3 поля, то запрос будет в 10 раз быстрее".
S>в 10 раз не будет. А вот нагрузочное тестирование сможет провалить, или в продакшене начнет тормозить, попробуй это на стадии спецификации угадать
Контракты, нарушение которых вызывает нефункционирование системы (провал тестов) должны быть как можно более явно прописаны. Неявные условности типа "шаг влево, шаг вправо — попытка к бегству, стреляю без предупреждения", — в итоге приводят к неподдерживаемой системе.

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

S>Проблема сама в том, что если начинать делать методы более "общими", то это очевидно будет давить на производительность.

Совсем неочевидно.

S> Причем даже не случае различных параметров, когда новый метод практически неизбежен, но и в случае когда новому клиенты вместо одного поля сущности требуется отобразить другое. Если тянуть из базы ВСЕ поля

А зачем тянуть все поля? Операцию проекции уже отменили?

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

S>есть таблица с 30 полями. Есть поиск по 3 полям, на выходе сущность с 6 полями. Делается индекс по 3 полям, оставшиеся 3 поля добавляются как included. Поиск по индексу сразу вернет сущность. Если тянем все 30 полей, то после поиска включается лукап остальных полей (что представляет собой ЕЩЕ один поиск уже по кластерному индексу тех-же самых данных), стоимость будет порядка 10-20% oт запроса. Это не считая логических чтений страниц всех этих полей, их транспортировки и прочего

Есть и другие моменты. К примеру блокировки. Если ты дернул из-за лишнего поля индекс, по которому кто то другой пишет с соотв. изоляцией, получишь блокировку.