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

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

_>>>Ну да, linq2db конечно получше, всего 100% накладных расходов, а не 500%. )))
G>>Да хоть 10000%, относительные величины не имеют никакого смысла.
G>>Имеет смысл влияние скорости linq на время ответа и пропускную способность. Причем в реальном приложении, а не синтетическом тесте.

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

_>>>Ну даже если забыть о нормальных реализация уже давно имеющихся в других СУБД, то хотя бы из того, что они исправили это в 2012-ом году. ))) Причём реализовав как раз как у других было.
G>>Ок, если ты настолько глуп — объясняю.
G>>SQL Server очень хорошо следует стандартам.
_>Хороший юмор. Это "top x" у нас соответствует стандарту, да? ) Да и вообще MS славится своим отношением к стандартам во всём. )))
Не следует. И что? Кто-то говорил о 100% соблюдении стандарта? Это неразумно, стандарт во многом не учитывает реальные кейсы.

G>>В стандартах ANSI не было (и насколько я знаю до сих пор нету) штатного способа разбиения резалтсета на страницы. Было через курсоры, но реализация курсоров оказывается медленнее операций с множествами.
_>Ну вот теперь и проявляется кто у нас на самом деле не знаком с SQL, а знаком исключительно с конкретной поделкой одной известной компании. Хотя я в общем то совсем не удивлён — почти всегда те, кто громче всех кричит о незнание других, на самом деле сами не особо разбираются. Тут таких много на форуме...
_>В стандарте SQL2008 оно появилось.
Да-да и в каком виде?

G>>Поэтому в T-SQL долго не включали операторы постраничного разбиения. А вот ranking functions как раз в стандарте есть и через них прекрасно делается разбиение на страницы.
G>>Только в конце 2000-х стало очевидно, что на стандарт уже все положили болт и тогда добавили операторы в T-SQL.
_>Зачем врать то? ) Появилось оно не в конце 2000-ых, а вполне себе в 2012, т.е. через несколько лет после появления в стандарте. И через десятилетие после того, как этим спокойно работали пользователи нормальных СУБД.
Ты наверное не понимаешь, что для того, чтобы что-то появилось в 2012 это надо было делать в 2008. Спецификации к следующей версии пишутся сильно заранее до релиза.

_>>>У тебя мозг уже не способен связать два последовательных абзаца? ) Перечитай ещё пару разу предыдущий абзац)))
G>>Ок, давай возьмем современные версии двух движков и ты на примере покажешь чем pl\sql в Postgres кардинально отличается от T-SQL. Ты не сможешь этого сделать. Поэтому все твои рассуждения — бредятина.

_>Похоже тебе надо ещё раз 10 перечитать тот абзац. ) Речь как раз и шла о том, что только в 2012-ом SQL Server приблизился к нормальным решениям. Т.е. речь шла о сравнение не современных решений, а предыдущих лет.
Слушай, ты как маленький. постраничная разбивка результатов никаких проблем никому не приносила с 2008 года. Это толко у тебя с этим были какие-то проблемы. Также как и со скоростью linq впрочем.

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


G>>Ты просто не понимаешь о чем они пишут.
G>>Они тебе говорят что для разных движков и даже разных версий одного движка одно и то же логическое выражение может быть записано по разному и давать разное быстродействие. Это означает, что в compile-time ты не сможешь сгенерировать оптимальный запрос к БД в принципе, а в runtime это можно сделать.

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

G>>Я тебе говорю о том, что даже в рамках одного движка linq с легкостью сгенерирует сотни похожих запросов и каждый будет оптимальным для своего сценария, а руками даже десять таких запросов написать и поддерживать невозможно.

_>Даже если не использовать готовую библиотечку генерации во время компиляции (типа обсуждаемой), то это всё равно не означает что надо каждый запрос прописывать руками. Ты там со своим linq похоже совсем уже забыл, что есть банальные операции со строками, функциям можно параметры передавать и т.п..
Конечно забыл это как страшный сон. В 2006 году у меня был проект с кучей склеек строк, багов было огромное количество, поддерживать это было невозможно.
Я прошел через это, а ты только теоретизируешь.

_>>>Да да, конечно не может. И написать код, генерирующий эти запросы он тоже не может. )))
G>>Если сможет, тогда у него получится linq. Или придется жертвовать выразительной силой, получая в итоге более универсальные и более тормозящие запросы. Ты же так и не смог показать генератор запросов, аналогичный linq по мощности, но без оверхеда.

_>Помнится в той старой темке ты говорил тоже самое (и даже ещё смешнее, что типа банальных join, groupby и т.п. нет). Но когда тебя ткнули в нос в соответствующие работающие примеры (причём даже не на форуме, а прямо в папке example той библиотечки, в которую ты сам не догадался заглянуть), то по тихому слился из дискуссии. Если сейчас попробовать повторить тоже самое, то не сомневаюсь в аналогичном результате.
Примеры не были работающими никогда, их невозможно было нигде запустить, чтобы банально проверить качество генерируемого sql. Я тебе и тогда предлагал превратить их в работающие, прогнать на сценариях с проекциями (самыми важными по сути), но ты слился, как и сейчас.

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

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

_>Вообще то и при использование параметров нормальный запрос будет выглядеть короче твоего чудища в хранимке. И при этом работать оптимизировано. Попробуй сам написать такое и увидишь. Или ты уже совсем разучился с этим своим linq и нужна подсказка? )
Я по-разному пробовал, результат не меняется.

G>>Ты опять показал свой профанизм.
G>>Подстановка параметров имеет два огроменных недостатка:
G>>1) SQL-инъекции в случае текстовых параметров, они гарантированно будут. Надежного метода экранирования практически нет.
_>
Сказать нечего, понятно.

G>>2) Каждый запрос будет компилироваться по новой. Это мееедленно и кушает память базы на хранение планов.
G>>С твоим подходом быстродействие упадет и приложение станет более уязвимым.
G>>Так что брось сразу эту затею и читай мануалы.

_>О, я смотрю что незнание проявляется всё больше и больше. Причём здесь уже включает даже твой любимый sql server, а не только сам язык sql. Похоже что ты слышал только о кэширование планов параметризованных программистом запросов. А о просто кэширование планов или об автопараметризации констант ты и не слышал видимо. Мда... )
Похоже ты только слова слышал, но смысла их не понимаешь.

1) Все движки БД компилируют запросы и кешируют планы
2) Если клеить строки с константами, то планов будет много и много времени уйдет на компиляцию. Из-за этого тормозит.
3) Почти во всех базах есть автопараметризация, когда в простых запросах подстановка заменяется параметром и компилируется параметризованный запрос и только один раз. Любой запрос с джоином простым не является.
4) Любой параметризованный запрос страдает от parameter sniffing problem.
5) Победить psp, где она имеет большой impact, можно через генерацию разных запросов для сочетаний параметров с разной селективностью. Чаще всего это нужно, когда в зависимости от присутствия параметра надо фильтровать таблицу.
6) С точки зрения программы надо клеить строки. Тут два варианта — руками или использовать linq. Руками — чревато ошибками, сложности с рефакторингом и поддержкой.

В каком месте этой цепочки ты хочешь обмануть реальность?


_>>>А какая разница в какой компании написан софт? ) Мы же языки/платформы/библиотеки обсуждаем...
G>>Не знаю что ты обсуждаешь, а меня инересуют что делают парни из SO.
G>>Парни из SO пишут код на C# и запускают его под вендой. А сторонние продукты запускают по nix потому что это дешевле.
G>>Тут никаких идеологических мотивов нет, только экономические.

_>А причём тут какая-то идеология? ) Это только у неадекватов с форумов она встречается, а нормальные люди тупо используют то, что дешевле. ))) И если готовые решения на C++, работающие под Linux оказываются быстрее и дешевле C# аналогов, работающих под виндой, то это и есть решающий фактор.
Именно. Но при этом писать дешевле и удобнее на .NET и запускать свой код под венду.

_>>>Без проблем. ) Но с PostgreSQL ну или чем-то ещё приличным. С кактусами возитесь сами.
G>>Ясно, слился.
_>Считай как хочешь. )
Так ты хочешь, а не я. Я тебе готов все средства представать, чтобы можно было сравнивать результаты.

_>>>Или Linq не умеет PostgreSQL?) Ну давай тогда возьмём что-нибудь совсем простенькое и популярное, типа sqlite. )))
G>>Все умеет, но никто не будет адаптировать существующие тесты для других движков. Это же не просто поставить постгрес, надо еще базу перенести, текстовые запросы переписать. Никто для тебя этого делать не будет.
G>>Или сам, или используй готовую базу на SQL Server.
_>Можем не использовать row sql запросы вообще (собственно нас же только сравнение с linq версией интересует). База переноситься в две консольные команды.
А тогда базы для сравнения не будет. Нужен эталонный запрос.
Если есть желание — вперед, переделывай все тесты под postgres.

G>>Но помоему уже все поняли, что доказать свои слова ты не можешь.
G>>Можешь не продолжать писать. Большего профана наверное на всем форуме не найдешь.
_>Ага, и поэтому ты пишешь мне по 3 сообщения в ответ на одно моё. И поэтому так нервничаешь в каждом из них. Я так и понял. )))
Я пытаюсь созранить баланс здравого смысла, поэтому приходится отвечать на твой бред.