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

_>Всем известно, что стандарты лишь закрепляют и формализуют давно существующие у лидеров направления решения. И действительно, если говорить о нашем конкретном вопросе, то данной функциональностью (со своим нестандартным синтаксисом) уже многие годы наслаждались пользователи нормальных СУБД. А реализовать через несколько лет после выхода стандарта — это поведение характерное для отстающих.
И че?

G>>Слушай, ты как маленький. постраничная разбивка результатов никаких проблем никому не приносила с 2008 года. Это толко у тебя с этим были какие-то проблемы. Также как и со скоростью linq впрочем.
_>С "2008-го года" — как мило. ))) У других такое уже десятилетиями работало. ))) Причём сразу в нормальном варианте (до которого MS дошла только в 2012-ом и только благодаря закреплению этого в стандарте SQL2008).
И че?

_>>>А вот сейчас похоже можно уже и с SQL Server без linq нормально жить.
G>> Ты сам начал разговор, с того, что SQL Server — хреновая СУБД и есть гораздо лучше. Вот обоснуй свои слова. Сейчас 2016 год если что.
G>>15 лет назад все СУБД были говном по сравнению с сегодняшними версиями.

_>Правильно, я и предлагаю сравнивать решения одного года. Если говорить про прошлое, то там у SQL Server один мрак (в сравнение с конкурирующими продуктами тех же лет!), к которому без linq и подходить то страшно. Сейчас уже похоже стало получше, подтянулись к стандарту...
Давай сравнивать решения 2016 года.

_>>>До тебя так и не дошло? ) Генерируется во время компиляции не сам запрос, а код его создания (склейки строк). Собственно иначе и невозможно, т.к. в запрос входят данные.
G>>Как до тебя не дошло, что строки могут получиться кардинально разными?
G>>Берем то же разбиение по страницам. До 2012 SQL Server тебе нужен был подзапрос с row_number, после 2012 подзапрос не нужен.
G>>Теперь покажи пример кода, который будет сгенерирован, чтобы поддерживать эти кейсы.
_>Во-первых такое тоже без проблем реализуется на тех же шаблонах. Но естественно в данной конкретной библиотечки ты такого не найдёшь, т.к. она родилась уже после 2013-го и для неё подобные ужасы неактуальны. )))
Если "без проблем", то почему "не найдешь" ? Авторы не хотят поддерживать больше движков? Или все таки не могут?
Ты сам себе противоречишь.

_>Примеры на гитхабе полностью компилируемые и исполняемые (собственно было бы странно иначе). Я проверял сам и может проверить любой наш читатель. Так что тут ты уже заврался сверх меры, причём на глазах у всех.
Ты предлагаешь тебе на слово поверить? Сделай тесты на этой библиотеке, докажи что не свистишь, заодно и проверим быстродействие.

_>>>А ты даже читать не умеешь похоже. Ответить на фразу "одинаково только если запрос написать полностью аналогичный процедуре, что бредово" фразой "если взять один и тот же запрос, то будет одинаков" может только реальный уникум.
G>>Тогда потрусь объясни что ты имеешь ввиду? Ты же у нас одаренный а плане SQL, иногда такие перлы выдаешь, что лучше не читать.
_>Я вроде как вполне ясно написал уже раз десять. Запрос будет существенно отличаться от хранимки и будет оптимальным. При условие что его пишет не альтернативно одарённый человек. Хотя бы потому, что оптимальная запись является короче того страшного запроса в хранимке, с которым ты там боролся.
Ну так напиши этот оптимальный запрос.

_>>>Вообще то и при использование параметров нормальный запрос будет выглядеть короче твоего чудища в хранимке. И при этом работать оптимизировано. Попробуй сам написать такое и увидишь. Или ты уже совсем разучился с этим своим linq и нужна подсказка? )
G>>Я по-разному пробовал, результат не меняется.
_>Совсем разучился уже со своим Linq. ))) string query="select ... where "+ship_date?"ship_date=@ship_date":"ship_date is null"; Заметно короче и проще твой страшной хранимки, не так ли? ) И при этом полностью оптимально с точки зрения создания планов...
Наконец-то, через 5 постов ты родил строку кода.
Надеюсь ты понял какую проблему надо решать.

Теперь задача посложнее:

if(categoryFilter != null)
{
   products = products.Where(p => p.Category.Name.StartsWith(categoryFilter));
}

Теперь от параметра не просто добавляется фильтр, а еще и делается джоин. Без параметров никаких джоинов нет.
Сама коллекция product может содержать быть отфильтрована и другими предикатами до фильтра по имени категории.
Как это сделать на склейке строк или твоей библиотеке?

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



G>>6) С точки зрения программы надо клеить строки. Тут два варианта — руками или использовать linq. Руками — чревато ошибками, сложности с рефакторингом и поддержкой.
_>Это как бы очевидно. Ну в случае C#. ))) И ты буквально повторяешь мои слова в этой теме раньше. Только забываешь добавить, что в обмен на преимущества статической проверки linq привносит оверхед в рантайм. Вопрос что важнее каждый для себя решает сам.
Да-да, только раньше ты не понимал какую проблему решает linq, но почитал про планы запросов, кеширование и psp, и наконец разобрался, молодец.
Но ты понял только половину проблемы — генерация оптимальных запросов. А вторая половина проблемы — затраты трудочасов на такую генерацию.

Выше для тебя пример, чтобы ты попробовал его изобразить с помощью склейки строк.

_>Ну а в некоторых других языка такой дилеммы нет, т.к. там встречается статическая проверка и без оверхеда в рантайме.
Вот тебе пример выше — покажи как статическая проверка в нем сработает.

G>>Так ты хочешь, а не я. Я тебе готов все средства представать, чтобы можно было сравнивать результаты.
_>Я тебе уже озвучил что мне требуется. ) Пример на C# (для сравнения) работающий с любой вменяемой СУБД (для Linq же это вроде не проблема, не так ли?) С SQL Server я никогда в жизни не встречался и начинать не планирую. )
Ты сейчас вертишься как уж на сковородке чтобы избежать прямого сравнения говноподелки с linq любыми способами.

Давай так:
1) ты вроде утверждал, что можно с помощью конфига подменить генерацию запросов в коде на C++, чтобы они работали для другой базы
2) Ты утверждал, что базу SQL Server можно быстро перегнать в posrtges
3) Ты говорил что выложишь исходники

То есть ты можешь взять базу northwind, перегать её в postgres, написать для нее тестовые запросы, выложить код на github.
А мы просто с гитхаба возьмем код, поменяем параметры чтобы тоже самое работало с SQL Server.
Так?

И ты работаешь с чем хочешь и сравнить потом можно. Так что приступай.