Здравствуйте, gandjustas, Вы писали:
G>>>Про автопараметризацию забудь, она работает в таких примитивных случаях, что нет смысла обсуждать. _>>И тут ты снова не прав, т.к. есть SET PARAMETERIZATION FORCED. Сразу скажу (а то тут есть некоторые любители домысливания за оппонентов), что я не призываю всё переделать под данную технику, а просто в очередной раз демонстрирую неверность твоих утверждений. G>Ты демонстрируешь только свой профанизм. G>Смотри что получается с FORCED: G>1) В приложении ты клеишь сроки с параметрами и генерируешь 100500 однотипных, но разных с точки зрения РСУБД, запросов. G>2) РСУБД парсит каждый запрос (это повторяется 100500 раз) и получает в итоге один параметризованный план G>Не проще генерировать параметризованный запрос в приложении и не тратить время на парсинг?
Это просто феерично. Если посмотреть на что направлен мой комментарий и на что отвечаешь потом ты. Причём я даже специально тогда отметил для особо одарённых, что здесь исключительно возражение на твоё высказывание о возможности работы автопараметризации только в примитивных случаях, а не призыв её использования. И всё же даже после такого явного предупреждения ты пишешь подобную ересь. Да же не знаю что сказать на такое...
_>>Вообще то я продемонстрировал инструмент с удобством лучше linq. Хотя бы потому, что он является полным отражением sql. В отличие от linq, у которого нет полного взаимного соответствия с sql. Например как насчёт CTE запросов на linq? ) G>Я тебе еще раз повторяю, все что ты продемонстрировал не умеет динамически собирать запросы и не умеет генерировать разные запросы для разных движков.
И динамические запросы без проблем делаются (собственно это можно было увидеть даже просто из того факта, что там по два вида всех конструкций, динамические и обычные) и генерация разного кода для разных СУБД тоже без проблем работает (в точности по тому же принципу, через коннекторы/провайдеры). Если по твоему есть какие-то конкретные примеры sql кода (динамические или статические, не важно), которые ты считаешь не могут быть записаны с помощью данной библиотеки, то давай, озвучь их.
А готов ли ты записать любой sql код с помощью Linq? ) Если я возьму например какой-нибудь рекурсивный CTE запросик...
G>Я тебе приводил пример как в linq добавление условия в where мрже приводить к добавлению джоина. Без этого говноподелки бесполезны чуть более чем полностью.
А вот такой ереси действительно нет и это очень хорошо. Допускать добавление такой тяжёлой вещи как join по желанию неких невнятных алгоритмов — это редкостный бред. Такие вещи должны явно декларироваться, чтобы программист мог легко оценить сложность запроса по одному взгляду на него.
_>>Ну т.е. у нас снова беседа свелась к оценки конкретных цифр. Т.е. никто не возражает что prepare эффективнее, остаётся только вопрос на сколько. G>Ни на сколько, ты опять забываешь про накладные расходы которые несет prepared statement. G>Ты думаешь если бы prepare был реально эффективнее, то его бы не использовали везде? Но по факту не используют.
Вообще то вполне себе используют. Не надо оценивать всех по своему маленькому мирку .net + SQLServer.
_>>Ну покажи где я такое предлагал. ))) G>Везде. Ты не говорил об ограничениях, это можно как-то по-другому понимать?
Вообще то изначально обсуждение касалось предкомпилированных запросов в linq2db, EF и т.п. И умеют ли они делать предкомпиляцию в СУБД (выяснилось что не умеют). Применимость самих предкомпилированных запросов linq2db, EF и т.п. мы тут не обсуждали, но очевидно, что их не используют повсеместно.
_>>О, ещё один в 1000 соединений... Ты что, хочешь использовать схему apache с отдельным потоком на каждый запрос пользователя или как? ) G>А при чем тут потоки? можно и с 50 потоками сгенерировать 100500 соединений. Более того, как раз асинхронная обработка запросов ограниченным пулом потоков как раз ведет к повышенной нагрузке на пул соединений.
Можно то можно. Только если начать обсуждать все теоретически возможные криворукие реализации, то подобная дискуссия точно ни к чему не приведёт.
G>>>Исключения настолько редки, что не имеет смысл их рассматривать. _>>О да, они страшно редки. Особенно учитывая популярность mysql и то, что её оптимизация частенько крутится как раз вокруг правильной настройки кэша запросов (для веба, с его статической природой самое оно). G>Для говносайтов с 1 посещением в месяц — отличная тема. Под нагрузкой не катит вообще. Ресурсы сервера БД сильно дороже, чем ресурсы отдельного сервера для кэша. G>Но ты об этом никогда не узнаешь, у тебя не было и не будет ни одного проекта с серьезной нагрузкой.
А где был разговор про тяжёлую нагрузку или ещё что? Твоё утверждение было просто про редкость использования данного механизма. Что явно является бредом как раз из-за распространённости mysql (пускай её при этом и используют не для самых тяжёлых случаев).
