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

_>>(ведь если выкинуть и linq, то можно ещё в несколько раз ускориться)...
AVK>Ага, языком.

Не, так же, как в вашем же любимом Решарпере. )))

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

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

_>>>(ведь если выкинуть и linq, то можно ещё в несколько раз ускориться)...
AVK>>Ага, языком.

_>Не, так же, как в вашем же любимом Решарпере. ))

Хм, а ты понимаешь, чем Linq2Objects от linq2db/sql отличаются ??

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

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

G>>Пару миллисекунд на запрос, это в несколько раз?

_>Так смотря какие запросы. ) Особенно в контексте того, что тут по сути обсуждался перенос сложных запросов из базы.

Для базы нет разницы написан запрос руками или сгенерирован Linq_ом. Linq в среднем делает запросы лучше, чем можно врукопашную написать. Во-первых Linq_ом проще нагенерить несколько запросов со стабильными планами, чем использовать один запрос с кучей параметров с нестабильным планом. Во-вторых с Linq проще делать проекции, а значит и проще покрывать индексами. В третьих композируемость Linq позволяет генерировать более сложные запросы, чем человек может вручную писать. Поэтому там где человек начнет использовать императивщину в SQL, запрос, сгенерированный Linq, будет соптимизировать встроенным оптимизатором БД.

Единственное что можно выйграть от отказа от linq — время обхода Expression Tree для построения SQL, но и для этого есть тулинг в виде компилированных запросов.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

С>>А можете подробнее написать, почему вы так считаете?

НС>Потому что в реальности структура БД почти всегда меняется намного реже, чем код. И,зачастую, на нее еще и не одна программа подвязана. Поэтому решения принимаются именно от структуры БД.
в начале разработки приложения происходит ровно наоборот. Поэтому EF с codefirst позволяет гораздо быстрее создавать приложения. А уже потом, когда структура базы устаканится, появятся другие приложения, работающие с базой надо будет переходить на database first.

С>>По моим впечатлениям, code first отсутсвует в linq2db только потому, что его написать не успели.
НС>Твои впечатления тебя обманывают. Такой задачи даже не ставилось.
И очень зря. Это бы снизило порог входя для использования linq2db в проектах.

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

VC>Весь критический по требованиям производительности тормозам код приходится переписывать выкидывать с помощью c++.

VC>c# и gb не нужен. Кто будет спорить тот или нехорошо себя ведёт, или c-код писАть не умеет c asm вставками.

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

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

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

С>По моим впечатлениям, code first отсутсвует в linq2db только потому, что его написать не успели.

Code first — это одноразовая фича. Как презерватив. Натягивается только на проектики демонстрационного уровня. В реальных проектах приносит большем проблем, чем пользы. Поэтому заниматься подобной фигнёй не было даже в планах.

В отличии от EF, linq2db — это сугубо утилитарный проект. Первыми в нём реализуются фичи, которые делают библиотеку полезной и применимой в реальных, а не демо-проектах. Например, в linq2db изначально уделялось серёзное внимание производительности и удобству отладки приложения, DDL и DML операциям. А такие стрёмные вещи как LoadWith делались в последнюю очередь.

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

G>в начале разработки приложения происходит ровно наоборот.

Это уж как кто привык. Мне последнее время удобнее поправить вообще в SSMS, иногда даже запросики руками погонять, а уж потом импортнуть все в проект.

G> Поэтому EF с codefirst позволяет гораздо быстрее создавать приложения.

Демки он быстрее позволяет создавать, а не приложения.

Здравствуйте, Ночной Смотрящий, Вы писали:

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

G>>в начале разработки приложения происходит ровно наоборот.

НС>Это уж как кто привык. Мне последнее время удобнее поправить вообще в SSMS, иногда даже запросики руками погонять, а уж потом импортнуть все в проект.

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

G>> Поэтому EF с codefirst позволяет гораздо быстрее создавать приложения.
НС>Демки он быстрее позволяет создавать, а не приложения.
Скорость создания приложения напрямую связана со скоростью создания демок. Выявить все потребности можно только показывая нечто работающее и чем быстрее это нечто создаешь, тем быстрее у тебя родится финальная версия.

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

G>Для базы нет разницы написан запрос руками или сгенерирован Linq_ом. Linq в среднем делает запросы лучше, чем можно врукопашную написать. Во-первых Linq_ом проще нагенерить несколько запросов со стабильными планами, чем использовать один запрос с кучей параметров с нестабильным планом. Во-вторых с Linq проще делать проекции, а значит и проще покрывать индексами. В третьих композируемость Linq позволяет генерировать более сложные запросы, чем человек может вручную писать. Поэтому там где человек начнет использовать императивщину в SQL, запрос, сгенерированный Linq, будет соптимизировать встроенным оптимизатором БД.

Ты не совсем понял мою позицию. Я не сторонник работы через склейку sql строк (хотя в этом тоже ничего ужасного нет, но всё же не очень удобно и безопасно) — естественно удобнее использовать специальные автоматические инструменты. Только вот они могут быть построены на очень разных принципах. И я соответственно считаю приемлемыми только те, которые вносят 0 накладных расходов. Так вот все производные от linq в этой области таковыми не являются. Как раз потому, что кому-то захотелось пристроиться к linq, а не создать отдельный инструмент специально для БД.

G>Единственное что можно выйграть от отказа от linq — время обхода Expression Tree для построения SQL, но и для этого есть тулинг в виде компилированных запросов.

Ну да, ну да) В начале берём кривой инструмент, а потом начинаем подпирать его костылями. Стандартная история. )))

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

_>Ну да, ну да) В начале берём кривой инструмент, а потом начинаем подпирать его костылями. Стандартная история. )))

Конечно стандартная. Без указания что с чем и на каких сценариях сравнивается стандартная история стандартно скатывается к "нравится-не нравится".

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

_>Ты не совсем понял мою позицию. Я не сторонник работы через склейку sql строк (хотя в этом тоже ничего ужасного нет, но всё же не очень удобно и безопасно) — естественно удобнее использовать специальные автоматические инструменты. Только вот они могут быть построены на очень разных принципах. И я соответственно считаю приемлемыми только те, которые вносят 0 накладных расходов. Так вот все производные от linq в этой области таковыми не являются. Как раз потому, что кому-то захотелось пристроиться к linq, а не создать отдельный инструмент специально для БД.
Действительно не пойму твою позицию. Ты вроде как против склейки строк, но Linq тебе не нравится. Тем не менее сейчас нету инструментов кроме Linq, которые позволяют из кода на C# генерировать SQL без склейки строк. Ты ищешь какие-то накладные расходы в linq, хотя я тебе уже написал, что это обход expression tree, от которого ты никуда не денешься, какой бы DSL ты не создал.

G>>Единственное что можно выйграть от отказа от linq — время обхода Expression Tree для построения SQL, но и для этого есть тулинг в виде компилированных запросов.
_>Ну да, ну да) В начале берём кривой инструмент, а потом начинаем подпирать его костылями. Стандартная история. )))
Предложи лучше, в чем проблема?

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

G>Действительно не пойму твою позицию. Ты вроде как против склейки строк, но Linq тебе не нравится. Тем не менее сейчас нету инструментов кроме Linq, которые позволяют из кода на C# генерировать SQL без склейки строк.

А, ну если ограничиваться C#, то возможно ты и прав, — я не могу сказать, что в курсе большинства его библиотек. Хотя даже если на C# в данный момент и нет подобных инструментов, то это не означает, что их невозможно сделать вообще.

G>Ты ищешь какие-то накладные расходы в linq, хотя я тебе уже написал, что это обход expression tree, от которого ты никуда не денешься, какой бы DSL ты не создал.

Это вполне может отрабатываться на этапе компиляции.

G>Предложи лучше, в чем проблема?

Если не ограничиваться C#, то без проблем. )

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

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

G>>Действительно не пойму твою позицию. Ты вроде как против склейки строк, но Linq тебе не нравится. Тем не менее сейчас нету инструментов кроме Linq, которые позволяют из кода на C# генерировать SQL без склейки строк.

_>А, ну если ограничиваться C#, то возможно ты и прав, — я не могу сказать, что в курсе большинства его библиотек. Хотя даже если на C# в данный момент и нет подобных инструментов, то это не означает, что их невозможно сделать вообще.

Ну ок, возьми не C#, а любой другой статически типизированный язык. В любом языке все придет к формированию деревьев выражений на основе конструкций языка, которые потом надо будет отобразить на метаданные классов и на базе этого построить SQL. Так что накладные расходы также будут присутствовать.

G>>Ты ищешь какие-то накладные расходы в linq, хотя я тебе уже написал, что это обход expression tree, от которого ты никуда не денешься, какой бы DSL ты не создал.
_>Это вполне может отрабатываться на этапе компиляции.
Только для статических запросов, но это как раз неинтересно. Сила linq-подобных инструментов в динамической композируемости запросов, которую никак на этапе компиляции не обработаешь.

G>>Предложи лучше, в чем проблема?
_>Если не ограничиваться C#, то без проблем. )
Попробуй не ограничиваться C#, и предложи другой способ.

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

Y>Да нет, наши потребности EF перекрывает, плюс для, скажем так, администранивного уровня, в споре "тулза от MS" vs "какие-то ребята-энтузиасты запилили прикольную штуку" выигрывает понятно что.
Ну если вам так уперлось, чтобы именно от MS — берите linq2Sql. Дешево и сердито, и всяко лучше EF.

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

G>Только для статических запросов, но это как раз неинтересно. Сила linq-подобных инструментов в динамической композируемости запросов, которую никак на этапе компиляции не обработаешь.

Это тебе так кажется) Вот та же самая склейка sql строк по твоему позволяет делать динамические запросы или нет? ) Или ты считаешь, что нельзя сделать инструмент, задающий эту же самую склейку, но автоматически на этапе компиляции? )

G>Попробуй не ограничиваться C#, и предложи другой способ.

Ну лично мне нравится например такое https://github.com/rbock/sqlpp11 решение. Потому как оно является полным отражением sql, только статически типизированным и т.п. Вообще предпочитаю "лёгкие" решения. Не в смысле быстродействия (в этом смысле все указанные мною примеры хороши), а в смысле функциональности. А если брать "тяжёлые" решения, то можно глянуть например на такое http://www.codesynthesis.com/products/odb/, но мне как-то приятнее иметь дело с "sql запросами". )))

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

_>Это тебе так кажется) Вот та же самая склейка sql строк по твоему позволяет делать динамические запросы или нет? ) Или ты считаешь, что нельзя сделать инструмент, задающий эту же самую склейку, но автоматически на этапе компиляции? )

Можно закэшировать те части запроса, которые известны на момент компиляции. Если запрос будет использоваться как есть, но с N фильтрами, можно положить в кэш запрос с N^2 комбинаций фильтров. А если запрос используется как источник для другого запроса, или производятся еще какие-то относительно сложные манипуляции, закэшировать ничего не получится, у компилятора ума не хватит.

Только вот компилятором на sql-сервер никак не положишь закэшированные планы запросов. А время перевода из синтаксического дерева в текст запроса ничтожно со временем построения плана. Так что все эти усилия с действиями на этапе компиляции есть вещь в себе, по факту не нужная.

Мне кажется, у вас есть некая профдеформация от low-level разработки для железа.

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

С>Можно закэшировать те части запроса, которые известны на момент компиляции. Если запрос будет использоваться как есть, но с N фильтрами, можно положить в кэш запрос с N^2 комбинаций фильтров. А если запрос используется как источник для другого запроса, или производятся еще какие-то относительно сложные манипуляции, закэшировать ничего не получится, у компилятора ума не хватит.

Так что у нас называется запросом то? Готовая sql строка или что? ) И в чём проблема её параметризации? )

С>Только вот компилятором на sql-сервер никак не положишь закэшированные планы запросов. А время перевода из синтаксического дерева в текст запроса ничтожно со временем построения плана. Так что все эти усилия с действиями на этапе компиляции есть вещь в себе, по факту не нужная.

Угу, и кэширования запросов в БД не бывает. ))) Кстати, а синтаксическое дерево в случае виртуальных функций формируется тоже не бесплатно. Хотя это уже мелочи. )))

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

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

S>>И потому что компилятор статически проверяет типизацию, заодно позволяя нам лёгким манием руки исправлять опечатки в названиях полей.
FLY>Это как это? Ты рефакторишь код в проекте, а с ним автоматом меняются названия полей таблицы в БД? Или что имелось ввиду?
Имелось в виду, что если я переименовываю поле в классе-DTO, то все мои linq-запросы обновляются автоматически. А маппинг на поле БД выполнен строго в одном месте, и мне не нужно беспокоиться о текстах сотен хранимок.

Здравствуйте, Yoriсk, Вы писали:
Y>Да нет, наши потребности EF перекрывает, плюс для, скажем так, администранивного уровня, в споре "тулза от MS" vs "какие-то ребята-энтузиасты запилили прикольную штуку" выигрывает понятно что.
Вы одной рукой пишете, что EF — страшный тормоз, а другой — что он перекрывает ваши потребности.
Или вы имеете в виду "перекрывает в том случае, если пользоваться не им, а хранимыми процедурами"? Тогда вопросов нет.