servitЕсли собрана, а план всё равно плохой, то это верный признак написать в WRC с классификатором проблемы "SQL Performance".Собрана, план плохой.
WRC тут не поможет, максимум скажут: "используйте %NOTOPOPT".
У нас запросы генерирует некий модуль, и там всегда присутствует строчка типа TOP 1000000.
А для каше, что TOP 1, что TOP 1000000 - план одинаковый. Может, если бы было TOP 1, он и был бы оптимальным.
Также, как каше не учитывает разную селективность по значениям полей, и тут просто нужно отключать индексы.

krvsaБлок А.Н.Я так сделал один раз и пожалел.
Вот и я с сомнением на то смотрю... Просто уш дюже долго вычисляется то ФИО... Даже не ожидал такого на "фаст-фастес" СУБД!
План запроса кривой. В данном случае не каше работает медленно, а каше делает кучу лишней работы.

krvsaБлок А.Н.Если хотите так делать, то делаете ссылку-вычисляемое поле. Не так уж потеряете по скорости, зато не будет проблем с целостностью данных.
Вот тут бы примерчик не помешал...
Как делать вычисляемые поля по свойствам этого же класса можно найти и в доке... А тут изменения в 3-тьей таблице... Как инициировать пересчет тех ФИО-полей?Ну и что, что изменения. Это вычисляемое поле хранить не надо. Сделайте метод в другом классе и используете его для вычисления.

servitБлок А.Н.У нас запросы генерирует некий модульМодуль можно улучшать?
Не очень понятен вопрос.
1. Имеются ли у меня полномочия? - да.
2. Вижу ли я в этом смысл? - пока нет.

С датой начала проблема в этом случае,
с отображением истории по принципу (дата начала-дата конца),
с редактированием истории тоже могут быть нелогичности.

У нас подобное есть, не нравится. Правда, у не совсем так сделано - в таблицы истории записи с датой отмены, а в основной таблице текущие значения. В плане прикрутить историю там, где ее не было - удобно, а работать с ней - не очень.