EF NET CORE Использование результата хранимой процедуры как поле в запросе к таблице

Есть унаследованный запрос

Для каждого id процедура возвращает только одно значение.

Как реализовать этот запрос в EF NET CORE?

0

Сообщение от sijuiem SQL 1 SELECT anything FROM anyprocedure(t.id)

А это точно работает? Или anyprocedure это не хранимка?
SELECT вызывается на UDF, View, Table. Хранимки вызываются через EXEC.

0

Сообщение от Andrey-MSK А это точно работает? Или anyprocedure это не хранимка?

Хранимка. Точно работет. Firebird

0

Сообщение от sijuiem Firebird

Уточнять нужно.

Добавлено через 18 секунд
Все СУБД ведут себя по разному...

Добавлено через 1 минуту
sijuiem, А вообще, вызов хранимки в SELECT для расчёта на каждой записи - это конечно жесть...

0

Сообщение от Andrey-MSK А вообще, вызов хранимки в SELECT для расчёта на каждой записи - это конечно жесть

Кто сказал что для каждой записи?
К таблице (в данном примере это не показано) применяется предложение where и подсчет идет только для этих записей.
Если бы была возможность логику процедуры реализовать в виде подзапроса... но это не реально.

Кратко логика процедуры заключается в определении вхождения в период родительской записи истории изменения периодов действия дочерних записей
Типа есть помещение и есть периоды проживания жильцов, но у жильцов есть свои периоды временного отсутствия. Так вот данный запрос определяет сколько жильцов реально проживало в определенный период.
Мы можем выбрать все помещения дома и знать сколько жильцов проживало в определенный день, месяц и т.п.
(В примере запроса для упрощения убрано все что касается параметров задания периодов и т.п.)

0

Сообщение от sijuiem Кто сказал что для каждой записи?

Потому что SELECT считает каждую запись в выборке. Будь там их тысяча или одна...
Нужно было делать через UDF (это View с параметрами) и JOIN. Вот тогда расчёт будет произведён один раз и таблицы соединятся, а дальше SELECT уже быстро всё сделает.

0

Сообщение от Andrey-MSK Потому что SELECT считает каждую запись в выборке. Будь там их тысяча или одна...

Сообщение от Andrey-MSK Нужно было делать через UDF (это View с параметрами) и JOIN. Вот тогда расчёт будет произведён один раз и таблицы соединятся, а дальше SELECT уже быстро всё сделает.

Однако это не относится к теме вопроса. Мы идем не туда.
Мне надо реализовать запрос в EF, а не менять структуру базы.

0

Сообщение от sijuiem Однако это не относится к теме вопроса. Мы идем не туда.

Это относится к теме производительности. Если сделать как надо, то тогда и в EF будет перевести гораздо проще, так как составные части запроса будут просто выборкой. Но дело ваше...

0

Сообщение от Andrey-MSK Если сделать как надо

Если делать как надо - понятие относительное.
В Firebird нет View с параметрами. )

0

Сообщение от sijuiem В Firebird нет View с параметрами. )

Уверены? 5.9. FUNCTION

Добавлено через 2 минуты
UDF - User Defined Function

0

Сообщение от Andrey-MSK Это относится к теме производительности

Хорошая тема, но я не просил как сделать производительнее, мне просто нужно решение именно моей проблемы.
К слову сказать корявенькое решение у меня есть, но оно мне не нравится, поскольку необходимо в качестве результата процедуры использовать одно из существующих полей таблицы таблицы запроса.

Добавлено через 6 минут

Сообщение от Andrey-MSK Уверены? 5.9. FUNCTION

View возвращает результат запроса, а это возвращает скалярное значение.
Совсем не то. В Firebird View c параметрами это и есть хранимая процедура.
Сними также можно строить джоины к таблицам, просто в данном случае джоин построить нельзя, т.к. процедура не возвращает полей для возможного соединения.

0

Сообщение от sijuiem т.к. процедура не возвращает полей для возможного соединения.

А кто мешает написать новую, которая будет возвращать что надо?

Сообщение от sijuiem а это возвращает скалярное значение

Согласен, не дочитал доку, там только скаляр...

0

Сообщение от Andrey-MSK А кто мешает написать новую, которая будет возвращать что надо?

Этот вариант рассматривается как крайний.

Стараемся как можно меньше вносить изменения в структуру базы, если что то можно решить без этого, т.к. это влечет реструктуризацию у клиентов, что связано с некоторыми накладными расходами.

0

Сообщение от sijuiem SQL 1 SELECT t.id,(SELECT anything FROM anyprocedure(t.id))  FROM anytable t

Если нужно только id + результат процедуры, то с таким же успехом на уровне кода можно через foreach пнуть нужное количество раз вызовов SP с параметром. Не думаю что будет радикально медленее.

Если таки очень хочеться чтобы ORM выдавала это как свойство, то можно запихнуть его расчётное, с ленивой подгрузкой (или нет). Я бы копал в эту сторону (вру, я бы написал новую SP возвращающую нужное).

0

Сообщение от Andrey-MSK sijuiem, А вообще, вызов хранимки в SELECT для расчёта на каждой записи - это конечно жесть...

Пойдет, в том же SQL Server-е можно делать cross apply/left outer apply, тоже самое.

0