Dima TАлексей Кпропущено...
Ну давай перечислим случаи, когда из-за ограниченных возможностей LINQ фрагмент запроса придётся разместить во view:

1. Рекурсивный запрос.
2. Необходимость использования хинтов.
3.......

Можешь продолжить?
Зачем надо костыль со view? А на кой нужен view если можно без view написать raw select?

часто, даже, и view не написать - where либо не получится из вне повесить, или это будет очень не оптимально.

Алексей Кfsharp_fsharpпропущено...


часто, даже, и view не написать - where либо не получится из вне повесить, или это будет очень не оптимально. Список сможешь продолжить?

я же про то что и вью не спасет. так что не в тот мне список

fsharp_fsharpАлексей Кпропущено...
Список сможешь продолжить?

я же про то что и вью не спасет. так что не в тот мне список

если это не мат вью

Алексей Кfsharp_fsharpпропущено...


я же про то что и вью не спасет. так что не в тот мне списокНу тогда рассказывай, почему where на view из вне не получится повесить. Всегда получалось.


потому что куча параметров может быть внурти запроса

Алексей Кfsharp_fsharpпропущено...



потому что куча параметров может быть внурти запросаНе тот случай. Во view вынесен маленький фрагмент запроса, который невозможно написать на linq. Чего-то большого и сложного в этой view по определению быть не может . Поэтому не надо проецировать на обсуждаемую view все свои воспоминания, связанные с огромными sql запросами.

ну конечно, прямо по-определению. с запросами с параметрами не приходилось работать?

hVosttfsharp_fsharpБД, особенно 10-15 лет назад, ничего не знали про LINQ. и как-то живут, по своим реляционным правилам. а БД, как и все в этом мире (2-й закон термодинамики неумолим), со временем тоже не молодеют, целлюлитом обрастают, или, даже, болеют. но живут.

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

fsharp_fsharpпроектирование БД под ОРМ - это зло.

Я сомневаюсь, что ты свою глупую мантру сможешь пояснить, поэтому даже просить аргументировать этот бред не буду.

Скажу только одно. Один из симптомов SQL головного мозга -- это когда человек вообще забывает для чего базы данных были придуманы. А придуманы они были хранить данные так, чтобы с ними было удобно работать. Если архитектура приложения, используемые ORM, задачи бизнеса в конце концов накладывают свои требования к проектированию БД для удобство выполнения задач и достижения конечной цели, а некий типа крутой БД архитектор встаёт раком со своими принципами, то он в этой же позе покидает команду и шурует в поисках такого же упоротого стада.

1. с БД может работать не один клиент
2. ОРМ - это всегда локализованная задача для клиента - он вырывает из БД только то, что надо приложению. а БД - там еще много других задач.
3. наезд на "типа крутой БД архитектор" может оправдываться только если ты сам "типа крутой БД архитектор". по твоим постам - это не так:

"С другой стороны на SQL можно написать ТАКОЕ, что в LINQ сделать почти не реально... вот только надо понимать, такие запросы изначально нафиг не нужны были в LINQ, а если пристально присмотреться, то скорее всего необходимость таких адских запросов — это большой косяк в разработке. Но то такое..."