Здравствуйте, alex_public, Вы писали:
_>Или же можно автоматически генерировать код склейки строк из чего-то удобного. Собственно Linq именно этим и занимается. Только почему-то в рантайме, а не во время компиляции проекта.
Потому что узкое место или хттп, или кеш, или сама база, а не серверный код на дотнете. Как ты собираешься улучшать пропускную способность, не устраняя никакого узкого места — не ясно.
Если ты считаешь, что узким местом является именно процессор, так и пиши. А то выглядит так, что ты оцениваешь работу с базой исключительно по количеству издержек на подготовку запроса.
_>>Более того, в своём предыдущем сообщение ты допустил очевидную демагогическую натяжку, которую я из-за спешки пропустил. Ты говорил о комфортном времени отклика для клиента в 100 мс и сравнивал его с вроде как незначительными на этом фоне 12 мс накладных расходов от linq. Только ты как-то забыл упомянуть, что на один запрос страницы с сервера очень редко когда приходится ровно один запрос в БД. В лучших и продуманных системах там их будет скорее всего два (один на какую-нибудь там авторизацию и второй на собственно данные), а в большинстве систем их гораздо больше (как раз потому что программисты не думают об оптимизации). В итоге даже в случае отсутствия большого числа одновременных пользователей накладные расходы от linq могут стать чувствительными из-за криворуких программистов (а в энтерпрайзе и т.п. полно таких). Ну а в случае большой нагрузки актуальным становятся накладные расходы даже от одного запроса в БД, т.к. нам надо обработать много пользователей за тоже время. G>Это не имеет значение, потому что время обработки запроса в БД оказывается сильно больше преобразования ET. При этом диск — первое ограничение для CУБД и веб-приложения. Поэтому время обработки ET в продакшене даст совершенно незаметные накладные расходы.
Ну вот если бы твоё первое предложение было справедливым, то и последнее стало бы таким. И это даже изредка так и есть (в редких случаях особо тяжёлых запросов). Но в большинстве случаев это не так. Ты же вроде как не опровергал цифры по тому тесту выше, не так ли? Они были выполнены для вполне стандартных условий. Так вот там были накладные расходы в 500%! Т.е. полное противоречие твоей первой фразе — время запроса не сильно больше, а наоборот сильно меньше накладных расходов.
_>>Вообще то как раз процессор и является узким местом (особенно если БД помещается в оперативку). Только не в так называемом веб-приложение (по сути тонкой прослойкой, между выполняющими основную работу http-сервером и СУБД), а в СУБД. G>Это зависит от запросов. Чаще всего узким местом является канал между базой и сервером приложений. G>Если база умещается в память, то один сервер БД способен обслуживать 10 веб-серверов с аналогичным железом. Только тогда СУБД может упереться в процессор.
Канал будет узким местом только при особой криворукости программистов, запрашивающих гораздо больше данных чем надо (пользователю то на страницу почти никогда не надо выдавать тысячи строк). Хотя... В этой темке вроде как сообщили, что SQL Server научился командам OFFSET и т.п. только в 2012-ом году. При такой убогости конечно можно и канал занять. )))
_>>Так что внесение дополнительных задержек ещё и поверх работы СУБД (причём сравнимых по времени) — это полный бред и допустимо только если нам реально наплевать на производительность (вполне реальный сценарий для странички васи пупкина или внутрикорпоративного приложения). G>Ты опять забыл, что linq создаст более оптимальные запросы и СУБД будет меньше напрягаться. Это приведет к увеличению быстродейсвтия.
Да да, я уже понял, что данный миф — это последняя надежда фанатов linq. Правда пока что во всей этой длинной теме не было ни единого практического подтверждения данного мифа.
G>>>Во-вторых сайт оплимпиды в сочи был написал c использованием linq и выдерживал огромные нагрузки на весьма скромном железе. _>>Это типа юмор такой? ))) Если про использование там linq я ничего не знаю, то про железо там всё хорошо известно (аж на Форбсе писали))) Это как раз тот самый случай, когда деньги никто не считал, т.к. репутация дороже. G>ХЗ о чем ты. Сайт сочи 2014 работал в azure и железо было довольно скромное для таких нагрузок. Причем олимпиада кончилась и серваки отключили, потратив 10% от стоимости покупки железа.
"Обычный разработчик напишет такую процедуру" — из этого бредового тезиса и высосана вся статья. С какой это стати рассматривать аналогом linq запроса хранимку, а не нормальный запрос? Кстати, у тех же SO одинаковое отношение и к linq и к хранимкам — это для них legacy, остатки которого они интенсивно вычищают из проекта.
G>По сути запрос можно плохо написать тремя способами — не указать проекцию и сделать универсальный запрос, вместо специализированного под параметры, использовать параметры с несовпадающими типами.
Ага, а на C++ неопытный разработчик способен создать код работающий медленнее аналога на Питоне. Означает ли этот факт то, что мы можем заявить "Питон позволяет писать более эффективный код, чем C++"? )
G>>>При использовании linq есть средства борьбы со сложностью запросов, поэтому запросы получаются более оптимальными. От этого и выигрыш. G>>>Примеров сотни. На этом сайте как раз увеличилась скорость от перехода на linq. _>>Покажи конкретный пример оптимизации запроса. G>Ссылка выше.
Я с большим удовольствием полюбуюсь как ты сумеешь записать данный запрос (а не хранимку) без данной "оптимизации". )
_>>Пока что единственные факты в данной теме представлены двумя ссылками на некие измерения и на архитектуру SO. И тем и другим фактам я как раз полностью доверяю. А вот ты ведёшь себя как-то скользко. Вроде как выступать против самих этих фактов не хочешь, но следствия из них не признаёшь. G>Я тебе уже давал ссылку на то, как linq сделает запрос быстрее. Ты проигнорировал.
Фу, с тобой невозможно прямо общаться. Ты просто не хочешь обсуждать неудобные тебе темы. Ну да ладно, не хочешь признавать истину и не надо. Мне как-то всё равно. )))
_>>К запросам конечно никак не относится. А относится к тому факту, что со временем процент использования windows и .net в их проекте неуклонно падает. G>Гениальный вывод За 8 лет процент .NET кода изменился со 100% до 98%, причем в неважных частях, это значит "неуклонно падает". Не занимайся примитивной демагогией.
Ты точно смотрел на картинку с их архитектурой? ) По твоему там 98% машин с windows?
_>>Винда у меня и так имеется. А вот с SQL Server связываться нет ни малейшего желания. G>Поставь visual studio, там есть localdb.
Оно у меня стоит на старой машине. А на новой решил не пачкать её этим монстром (который кстати половину винды меняет при установке), т.к. всё равно не использую.
_>>Давай так, если ты сделаешь мне один архивчик с исходниками тестов на C#, необходимыми для их построения библиотеками (СУБД желательно PostgreSQL, хотя можно и какой-нибудь sqlite для простоты) и каким-нибудь bat файлом для сборки, то я обязуюсь сделать точный аналог этих тестов на той C++ библиотечке и провести тестирование на своей машине. Выложив потом и результаты измерений и исходники тестов. G>Да конечно, верить тебе на слово?
До тебя так и не дошло? ) Проблема не в исходниках, а в сборке. Там же не просто обычный пример на C#, который я могу собрать в командной строке. Там используются всяческие посторонние библиотеки. Соответственно чтобы собрать такое мне надо их все руками скачать, поставить и т.п. А потом это всё ещё как-то прописывать в командную строку компилятора. Если бы мне это надо было по делу, то я конечно же разобрался бы (скорее всего настроил какие-то автоматические инструменты сборки и т.п.), потратив сколько то часов. Но ради форумного спора я такого делать не буду. Вот если мне кто-то подготовит собираемый C# вариант, то я без проблем сделаю C++ аналог (соответствующие библиотеки у меня развёрнуты, так что это будет дело 10 минут) и проведу тесты.
_>>У тебя начался повтор по второму кругу? ) Тебе подсказать ссылку на ту нашу старую тему, где всё это уже было и ты в итоге убедился, что любые запросы делаются без проблем? ) G>Нет, ты покажи код на github, который я на своей машине запустить могу. G>Ты же крутишься как уж на сковородке, чтобы работающий код не показывать.
Вообще то компилируемые примеры были прямой в том нашем старом обсуждение. Причём они были даже не мои, а от авторов библиотеки. Только ты в начале не смог их там даже найти (и поэтому долго говорил что библиотека не способна сделать join или groupby). Потом тебе их показали и ты признал что оно работает (наверное, т.к. собрать и проверить тебе тоже было не по силам). Так зачем тебе ещё какие-то компилируемые примеры, если ты даже с самыми базовыми примерами не знаешь что делать? )
Здравствуйте, Ikemefula, Вы писали:
_>>Не было на видео ни одной умной оптимизации, обещанной тобой. Только тупо подстановка разных особенностей синтаксиса конкретной СУБД. Такое без проблем запишется. I>С чем ты сравнивал ? I>Раз уж ты не веришь, что линк провайдер оптимизирует запросы, вот, смотри сам I>https://github.com/linq2db/linq2db/blob/master/Source/SqlQuery/SelectQueryOptimizer.cs
Не надо мне какие-то исходники показывать. Покажи просто один linq запрос и генерируемые из него оптимизированные sql строки под разные СУБД. Всё. Такая простая вещь будет 100% доказательством. Однако что-то никто не может показать ни единого примера уже сколько дней после "анонса" здесь этой чудесной возможности.
Здравствуйте, Ikemefula, Вы писали:
I>>>Знатоки С++ регулярно радуют откровениями, рассказывают что де можно всё в одном файле делать. Дескать 'три строчки и скорость ого-го-ни-одной-базе-не-снилась-почти-как-память'. Вот, к слову, именно ты не далее чем год назад рассказывал про чудеса виртуальной памяти, когда предлагал компилировать весь сайт вместе с темплейтами и тд и тд в один экзешник на vide.d. Это ровно тот же случай, только сбоку. _>>Ну вообще если речь о чём-то типа хранения в файле значений по ключу или вообще фиксированной структуры, то очевидно, что будет быстрее любой sql БД. А у тебя есть в этом сомнения? ) I>Есть. I>1 нужны вообще все гарантии, которые даёт движок БД. Без этого твоя поделка никому не интересна. I>2 нужна масштабируемость. I>3 ты не забыл, что данные нужны не одному инстанцу, а целому кластеру ? То есть, сетевой интерфейс тоже входит в необходимый минимум, более того, не просто интерфейс, с учетом п1 и п2 и всех возможных оптимизаций. I>4 физическая память не резиновая, у тебя никогда не будет коммита 1 к 1. Помнишь это ? I>Как только ты решишь проблемы 1, 2, 3 и 4, у тебя получится самопальный движок базы данных.
1. Даже если говорить о варианте не фиксированной структуры, а некой системы ключ-значени, то это всё равно получится не SQL БД.
2. Я не буду писать это сам, а возьму готовое решение. Redis если в чужом процессе и LevelDB/lmdb если в своём процессе.
3. И да, это будет намного быстрее любой SQL БД.
4. Ну а если мне понадобится хранить фиксированную структуру, то этот самый отображаемый в память файл (с тупо зашитой C++ структурой) будет ещё намного быстрее любых Redis'ов и т.п.
_>>Ну и в любом случае, даже если говорить о подобном хранение данных, то причём тут собственно шаблоны? ))) I>Твоя любимая песня: "нулевой оверхед !!!!111одинодин"
Для нулевого оверхеда совершенно не требуется использовать метапрограммирование на шаблонах C++. Для этого достаточно просто программировать на C++ в его родном стиле (а не как на Java/C#). Метапрограммирование всплывает в основном в весьма специфических случаях, когда надо задать внутри C++ некий встроенный DSL, проверяемый и оптимизируемый компилятором. Например мне встречались: SQL, регулярные выражения, грамматика парсера, таблица конечного автомата.
Что касается данного примера, то очевидно, что для сохранения данных в файл без оверхеда никакое метапрограммирование не требуется. )))
Здравствуйте, alex_public, Вы писали:
_>Они были выполнены для вполне стандартных условий. Так вот там были накладные расходы в 500%! Т.е. полное противоречие твоей первой фразе — время запроса не сильно больше, а наоборот сильно меньше накладных расходов.
Где ты видел 500% ? Это твои больные фантазии.
Условия в тестах вовсе не стандартные. Стандартные условия для БД — данные не находятся в памяти, их надо поднимать с диска. Именно под такой сценарий проектируются РСУБД. Для веба это зачастую верное предположение.
А в тестах на быстродействие Linq наоборот пытаются воздействие базы свести к минимуму — берут небольшие БД, повторяют одинаковые запросы много раз.
_>>>Вообще то как раз процессор и является узким местом (особенно если БД помещается в оперативку). Только не в так называемом веб-приложение (по сути тонкой прослойкой, между выполняющими основную работу http-сервером и СУБД), а в СУБД. G>>Это зависит от запросов. Чаще всего узким местом является канал между базой и сервером приложений. G>>Если база умещается в память, то один сервер БД способен обслуживать 10 веб-серверов с аналогичным железом. Только тогда СУБД может упереться в процессор.
_>Канал будет узким местом только при особой криворукости программистов, запрашивающих гораздо больше данных чем надо (пользователю то на страницу почти никогда не надо выдавать тысячи строк).
_>Хотя... В этой темке вроде как сообщили, что SQL Server научился командам OFFSET и т.п. только в 2012-ом году. При такой убогости конечно можно и канал занять. ))) Ты очередной раз расписался в незнании SQL. С 2008 года можно было через row_count() сделать постраничное разбиение, оно работает также как offset.
Примерно в то же время появился linq, который для .Top и .Skip функций генерировал корректный код.
G>>Ты опять забыл, что linq создаст более оптимальные запросы и СУБД будет меньше напрягаться. Это приведет к увеличению быстродейсвтия. _>Да да, я уже понял, что данный миф — это последняя надежда фанатов linq. Правда пока что во всей этой длинной теме не было ни единого практического подтверждения данного мифа.
А какое "практическое подтверждение" ты хочешь увидеть? Тебе уже написали много людей, которые умнее тебя и имеют больше опыта. Я привел тебе пример из поста, ты все равно не веришь. Если ты поищешь по этому форуму, то увидишь посты авторов rsdn о быстродействии linq в сравнении с рукопашными запросами.
Пока что больший миф, это возможность на C++ генерировать оптимальные запросы в compile time. Этого вообще никто никогда не видел.
G>>>>Во-вторых сайт оплимпиды в сочи был написал c использованием linq и выдерживал огромные нагрузки на весьма скромном железе. _>>>Это типа юмор такой? ))) Если про использование там linq я ничего не знаю, то про железо там всё хорошо известно (аж на Форбсе писали))) Это как раз тот самый случай, когда деньги никто не считал, т.к. репутация дороже. G>>ХЗ о чем ты. Сайт сочи 2014 работал в azure и железо было довольно скромное для таких нагрузок. Причем олимпиада кончилась и серваки отключили, потратив 10% от стоимости покупки железа. _>http://www.forbes.com/sites/benkepes/2014/02/04/adobe-and-microsoft-team-up-to-stream-sochi-from-the-cloud/
Это про стриминг, а я про сайт.
_>С какой это стати рассматривать аналогом linq запроса хранимку, а не нормальный запрос?
Ты опять показываешь профанизм, бросай. В чем отличие "хранимки" от "нормального запроса" в этом случае? Даю подсказку — ни в чем, абсолютно одинаковое поведение.
G>>По сути запрос можно плохо написать тремя способами — не указать проекцию и сделать универсальный запрос, вместо специализированного под параметры, использовать параметры с несовпадающими типами. _>Ага, а на C++ неопытный разработчик способен создать код работающий медленнее аналога на Питоне. Означает ли этот факт то, что мы можем заявить "Питон позволяет писать более эффективный код, чем C++"? )
C++ и Python языки с примерно равной выразительной силой и набором средств декомпозиции.
А SQL и Linq обладают разными наборами средств. В Linq легко декомпозировать и композировать запросы, в SQL такого нет.
G>>>>При использовании linq есть средства борьбы со сложностью запросов, поэтому запросы получаются более оптимальными. От этого и выигрыш. G>>>>Примеров сотни. На этом сайте как раз увеличилась скорость от перехода на linq. _>>>Покажи конкретный пример оптимизации запроса. G>>Ссылка выше.
_> _>Я с большим удовольствием полюбуюсь как ты сумеешь записать данный запрос (а не хранимку) без данной "оптимизации". )
Разницы не будет никакой. Каждый запрос кеширует план при первом исполнении, также как и хранимая процедура.
_>>>Пока что единственные факты в данной теме представлены двумя ссылками на некие измерения и на архитектуру SO. И тем и другим фактам я как раз полностью доверяю. А вот ты ведёшь себя как-то скользко. Вроде как выступать против самих этих фактов не хочешь, но следствия из них не признаёшь. G>>Я тебе уже давал ссылку на то, как linq сделает запрос быстрее. Ты проигнорировал. _>Фу, с тобой невозможно прямо общаться. Ты просто не хочешь обсуждать неудобные тебе темы. Ну да ладно, не хочешь признавать истину и не надо. Мне как-то всё равно. )))
Да-да, тебе все равно. Ты как не понимал как создаются нагруженные приложения, так и не понимаешь
_>>>К запросам конечно никак не относится. А относится к тому факту, что со временем процент использования windows и .net в их проекте неуклонно падает. G>>Гениальный вывод За 8 лет процент .NET кода изменился со 100% до 98%, причем в неважных частях, это значит "неуклонно падает". Не занимайся примитивной демагогией. _>Ты точно смотрел на картинку с их архитектурой? ) По твоему там 98% машин с windows?
Я про windows писал? *nix они используют по одной причине — "better money allocation". К вопросам разработки оно не относится.
_>>>Давай так, если ты сделаешь мне один архивчик с исходниками тестов на C#, необходимыми для их построения библиотеками (СУБД желательно PostgreSQL, хотя можно и какой-нибудь sqlite для простоты) и каким-нибудь bat файлом для сборки, то я обязуюсь сделать точный аналог этих тестов на той C++ библиотечке и провести тестирование на своей машине. Выложив потом и результаты измерений и исходники тестов. G>>Да конечно, верить тебе на слово? _>Не хочешь, не верь. Тогда и тестов не будет. G>>Исходники здесь: https://bitbucket.org/liiws/ormtestnorthwind/src
_>До тебя так и не дошло? ) Проблема не в исходниках, а в сборке. Там же не просто обычный пример на C#, который я могу собрать в командной строке.
Давай я тебе дам виртуалку с SQL Server и VS, а ты все сделаешь, ок?
Здравствуйте, alex_public, Вы писали:
_>Это уже не верно, т.к. относится разве что к системам клиент-сервер с одним клиентом. В случае же большого числа клиентов проблемы возникают и в других местах.
Продолжайте бредить. Я вам говорю про экстремальный случай веб-приложений, где "число клиентов" стремится к бесконечности. _>Хорошо видно, что как раз с сетевой частью справляются одиночные устройства. С работой БД уже похуже, требуется 4 сервера. А вот с работой приложений всё совсем печально — аж 11 серверов.
Хорошо видно, что вы вообще ничего не смыслите в архитектуре высоконагруженных приложений. Потому что эта картинка полностью подтверждает мою позицию. Stateful-часть системы масштабируется с большим трудом.
Добавление пятого сервера в кластер запросто может не улучшить, а ухудшить общие параметры производительности.
Поэтому идея "давайте сэкономим на генерации хорошего SQL и скомпенсируем удвоением числа RDBMS-узлов" не взлетает.
Зато stateless-компоненты прекрасно масштабируются, поэтому лишние наносекунды на обход expression trees для построения чуть более хорошего SQL легко скомпенсировать добавлением дополнительных узлов.
_>Шаблонный код для для записи в файл? ) Это ты где такого нахватался интересно? )))
Да есть тут у нас фанаты в форумах про архитектуру. _>В общем основная идея из всех твоих высказываний сводится к тому, что при наличие криворуких недоучек в команде linq позволит как-то скомпенсировать эту их криворукость? ) Ну не знаю, не проверял. ))) У меня как бы таких проблем нет и в команде только профи. )
Я уже разжёвывал подробно до букв, почему криворукость программиста ортогональна применению linq. А ваша уверенность в том, что "профи" в командном зачёте обыграет Linq провайдера по подготовке dialect-specific SQL основана исключительно на вашей некомпетентности.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
I>>4 физическая память не резиновая, у тебя никогда не будет коммита 1 к 1. Помнишь это ? I>>Как только ты решишь проблемы 1, 2, 3 и 4, у тебя получится самопальный движок базы данных.
_>1. Даже если говорить о варианте не фиксированной структуры, а некой системы ключ-значени, то это всё равно получится не SQL БД. _>2. Я не буду писать это сам, а возьму готовое решение. Redis если в чужом процессе и LevelDB/lmdb если в своём процессе. _>3. И да, это будет намного быстрее любой SQL БД. _>4. Ну а если мне понадобится хранить фиксированную структуру, то этот самый отображаемый в память файл (с тупо зашитой C++ структурой) будет ещё намного быстрее любых Redis'ов и т.п.
Я указал 4 обязательных пункта, которые нужны для внятного приложения. Отображаемый в память файл не проходит под п1, 2 и 3. п3 вместе с п1 вызывает серьезные сомнения, поскольку no-SQL не могут дать тех гарантий, что дает SQL DB. п2 и п4 — противоречие, не то файл смаппить, не то Redis взять
_>Что касается данного примера, то очевидно, что для сохранения данных в файл без оверхеда никакое метапрограммирование не требуется. )))
А как ты собираешься типизировать запросы ? Они то никуда не деваются. Или ты намекаешь, что раз сторадж сменился, то не худо бы код на sqlpp переписать ?
Здравствуйте, alex_public, Вы писали:
_>Канал будет узким местом только при особой криворукости программистов, запрашивающих гораздо больше данных чем надо (пользователю то на страницу почти никогда не надо выдавать тысячи строк). Хотя...
Тут один программист так налабал запрос, что он выливался в потенциальное сканирование таблицы без всякой на то необходимости
даже без предоставления данных пользователю и собирался дальше делать только хуже.
Как ты там себя назвал?
_>>>Что такое "более общие и менее оптимальные запросы"? Ты вообще о чём? SQL достаточно простой и точный язык. Как там вообще можно накосячить, если конечно не пытаться специально?
Т.е., ты лажал в собственных примерах специально?
Здравствуйте, alex_public, Вы писали: I>>С чем ты сравнивал ? I>>Раз уж ты не веришь, что линк провайдер оптимизирует запросы, вот, смотри сам I>>https://github.com/linq2db/linq2db/blob/master/Source/SqlQuery/SelectQueryOptimizer.cs
_>Не надо мне какие-то исходники показывать. Покажи просто один linq запрос и генерируемые из него оптимизированные sql строки под разные СУБД. Всё. Такая простая вещь будет 100% доказательством. Однако что-то никто не может показать ни единого примера уже сколько дней после "анонса" здесь этой чудесной возможности.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
_>>>Не было на видео ни одной умной оптимизации, обещанной тобой. Только тупо подстановка разных особенностей синтаксиса конкретной СУБД. Такое без проблем запишется. I>>С чем ты сравнивал ? I>>Раз уж ты не веришь, что линк провайдер оптимизирует запросы, вот, смотри сам I>>https://github.com/linq2db/linq2db/blob/master/Source/SqlQuery/SelectQueryOptimizer.cs
_>Не надо мне какие-то исходники показывать. Покажи просто один linq запрос и генерируемые из него оптимизированные sql строки под разные СУБД. Всё. Такая простая вещь будет 100% доказательством. Однако что-то никто не может показать ни единого примера уже сколько дней после "анонса" здесь этой чудесной возможности.
Вот, я делал пулл реквест, он еще не принят, но суть того что можна сотворить с SQL, понять сможешь из линка ниже
Здравствуйте, gandjustas, Вы писали:
_>>Они были выполнены для вполне стандартных условий. Так вот там были накладные расходы в 500%! Т.е. полное противоречие твоей первой фразе — время запроса не сильно больше, а наоборот сильно меньше накладных расходов. G>Где ты видел 500% ? Это твои больные фантазии.
Вот прямо здесь http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html в тесте "Simple TOP 10 query" EF показывает такие феерические результаты.
G>Условия в тестах вовсе не стандартные. Стандартные условия для БД — данные не находятся в памяти, их надо поднимать с диска. Именно под такой сценарий проектируются РСУБД. Для веба это зачастую верное предположение. G>А в тестах на быстродействие Linq наоборот пытаются воздействие базы свести к минимуму — берут небольшие БД, повторяют одинаковые запросы много раз.
Ну так кто бы спорил, что если обслуживать исключительно запросы со временем исполнения в секунду и больше, то тормоза Linq даже в лупу не увидишь. Только вот что-то людям оказывается больше нужны совсем другие запросы (смотри тот же SO).
_>>Канал будет узким местом только при особой криворукости программистов, запрашивающих гораздо больше данных чем надо (пользователю то на страницу почти никогда не надо выдавать тысячи строк). _>>Хотя... В этой темке вроде как сообщили, что SQL Server научился командам OFFSET и т.п. только в 2012-ом году. При такой убогости конечно можно и канал занять. ))) G> Ты очередной раз расписался в незнании SQL. С 2008 года можно было через row_count() сделать постраничное разбиение, оно работает также как offset. G>Примерно в то же время появился linq, который для .Top и .Skip функций генерировал корректный код.
Не в незнание SQL, а в незнание одной убогой СУБД под названием SQL Server, на знание которой я никогда и не претендовал (даже близко не видел и не планирую). Ну и даже если с 2008-го года существовал некий кривой костыль для данной функциональности (который они заменили на приличный синтаксис только в 2012-ом), то это всё равно смешно, т.к. с нормальными СУБД люди пользуются (и с нормальным синтаксисом) данной функциональностью уже не первое десятилетие.
Да, но я теперь больше понимаю почему дотнетчики так фанатеют от различных вариаций linq2database (буду так называть их все вместе, чтобы не было путаницы с одной конкретной). Многие из них обречены на работу с SQL Server, а похоже что писать для него чистый SQL крайне печально. Во всяком случае было ещё совсем не давно. )))
G>А какое "практическое подтверждение" ты хочешь увидеть? Тебе уже написали много людей, которые умнее тебя и имеют больше опыта. Я привел тебе пример из поста, ты все равно не веришь. Если ты поищешь по этому форуму, то увидишь посты авторов rsdn о быстродействии linq в сравнении с рукопашными запросами.
Это которые с хранимок перелезали? ) Ну да, ну да, смешно. )))
А подтверждение нужно очень простое. Я уже не раз писал. Пример linq запроса и примеры оптимизированного им под конкретные СУБД sql кода. Что может быть проще? Но пока в теме не было ни одного такого примера. Хотя фанаты анонсировали именно такую возможность, как главное преимущество.
G>Пока что больший миф, это возможность на C++ генерировать оптимальные запросы в compile time. Этого вообще никто никогда не видел.
Ты научись читать внимательно. Речь не о том какой код в этой процедуре, а о самом факте написания процедуры.
_>>С какой это стати рассматривать аналогом linq запроса хранимку, а не нормальный запрос? G>Ты опять показываешь профанизм, бросай. В чем отличие "хранимки" от "нормального запроса" в этом случае? Даю подсказку — ни в чем, абсолютно одинаковое поведение.
Нормальный запрос — это sql строка, передаваемая некой функции типа sql_execute(""). Так вот я с большим удовольствием посмотрю на твой код (на том же C#) создания этой sql строки с использованием той же самой C# переменной dateTime, как в твоём linq варианте.
Подсказка-анонс: твой неоптимизированный sql вариант (с которым ты вроде как борешься и побеждаешь его с помощью linq) будет намного длиннее и неудобнее простейшего оптимизированного и соответственно встретится только у очень странных людей.
_>>Ага, а на C++ неопытный разработчик способен создать код работающий медленнее аналога на Питоне. Означает ли этот факт то, что мы можем заявить "Питон позволяет писать более эффективный код, чем C++"? ) G>C++ и Python языки с примерно равной выразительной силой и набором средств декомпозиции. G>А SQL и Linq обладают разными наборами средств. В Linq легко декомпозировать и композировать запросы, в SQL такого нет.
Да, соответствие между SQL и Linq не полное. Это может быть как плюсом (где-то синтаксис выразительнее) так и минусом (программист не полностью контролирует результат, что как раз не нравилось команде SO). Кстати тут наблюдается очень близкая аналогия с тем же сборщиком мусора. Новичку на простом проекте это помогает, а профессионалом в сложных задачах только мешает.
_>>Ты точно смотрел на картинку с их архитектурой? ) По твоему там 98% машин с windows? G>Я про windows писал? *nix они используют по одной причине — "better money allocation". К вопросам разработки оно не относится.
Ну во-первых я писал в том числе и про windows. То, что ты отвечаешь только на удобную тебе часть моей фразы, для меня не новость. Во-вторых изменение платформы вполне себе влияет и на разработку, т.к. под линухом там запускают совсем не .net код.
_>>До тебя так и не дошло? ) Проблема не в исходниках, а в сборке. Там же не просто обычный пример на C#, который я могу собрать в командной строке. G>Давай я тебе дам виртуалку с SQL Server и VS, а ты все сделаешь, ок?
Я же сказал, с C#, SQL Server и т.п. кактусами возитесь сами. У меня нет времени разбираться в их кривых костылях. Я готов повозиться только с C++ аналогом. Плюс, чтобы провести тесты на одной машине я готов запустить подготовленный мне пакет. )
Здравствуйте, Sinclair, Вы писали:
_>>Хорошо видно, что как раз с сетевой частью справляются одиночные устройства. С работой БД уже похуже, требуется 4 сервера. А вот с работой приложений всё совсем печально — аж 11 серверов. S>Хорошо видно, что вы вообще ничего не смыслите в архитектуре высоконагруженных приложений. Потому что эта картинка полностью подтверждает мою позицию. Stateful-часть системы масштабируется с большим трудом. S>Добавление пятого сервера в кластер запросто может не улучшить, а ухудшить общие параметры производительности. S>Поэтому идея "давайте сэкономим на генерации хорошего SQL и скомпенсируем удвоением числа RDBMS-узлов" не взлетает. S>Зато stateless-компоненты прекрасно масштабируются, поэтому лишние наносекунды на обход expression trees для построения чуть более хорошего SQL легко скомпенсировать добавлением дополнительных узлов.
Т.е. изначальный тезис о том, что "главное узкое место — это транспорт данных между клиентом и сервером (HTTP)" уже не вспоминаем... Это правильно.)))
Да, безусловно главная проблема масштабирования это СУБД. Собственно потому и расплодились не так давно nosql решения, что sql сервера стали частенько достигать пределов вертикально масштабирования (ну во всяком случае за вменяемые деньги), а на автоматическое горизонтальное они не способны.
Но это совершенно не означает, что теоретическая возможность нормального горизонтального масштабирования кода "приложения" (хотя странно называть этим громким словом тонкий слой скриптов между http демоном и sql сервером) даёт право на выкидывание денег на соответствующие сервера впустую (на выполнение ненужной задачи, которая существует только из-за кривых инструментов программистов).
_>>В общем основная идея из всех твоих высказываний сводится к тому, что при наличие криворуких недоучек в команде linq позволит как-то скомпенсировать эту их криворукость? ) Ну не знаю, не проверял. ))) У меня как бы таких проблем нет и в команде только профи. ) S>Я уже разжёвывал подробно до букв, почему криворукость программиста ортогональна применению linq. А ваша уверенность в том, что "профи" в командном зачёте обыграет Linq провайдера по подготовке dialect-specific SQL основана исключительно на вашей некомпетентности.
Давай всё же определимся о чём конкретно идёт речь. А то в данной дискуссии похоже постоянно путаются три разные вещи:
1. Генерация sql кода с синтаксисом соответствующим конкретной СУБД. Имеется везде (и linq ORM и в том C++ решение на шаблонах и ещё много где).
2. Частичная оптимизация изначально криво записанных запросов (вне зависимости от вида СУБД). Никчемная возможность, полезная разве что совсем новичкам, а профессионалам только мешающая (см. пример тех же SO). Нигде кроме Linq не видел (ну MS славится своими Визардами и т.п. игрушками для снижения порога входа, правда следствием становится сплошной индусо-код) и надеюсь не увидеть в будущем.
3. Умная оптимизация запросов с учётом особенностей конкретной СУБД. Вот такое действительно было бы очень интересно. И т.к. подобного точно нет в обсуждаемом C++ решение или тем более голых строках, то это реально могло бы подтвердить тезис о возможности Linq формировать более оптимальные запросы. Только вот не смотря на анонс существования данной возможности в Linq ORM ни единого (!) примера, подтверждающего это на практике, пока так и не было представлено. Так что данную возможность мы пока что считаем мифом.
Здравствуйте, Ikemefula, Вы писали:
_>>1. Даже если говорить о варианте не фиксированной структуры, а некой системы ключ-значени, то это всё равно получится не SQL БД. _>>2. Я не буду писать это сам, а возьму готовое решение. Redis если в чужом процессе и LevelDB/lmdb если в своём процессе. _>>3. И да, это будет намного быстрее любой SQL БД. _>>4. Ну а если мне понадобится хранить фиксированную структуру, то этот самый отображаемый в память файл (с тупо зашитой C++ структурой) будет ещё намного быстрее любых Redis'ов и т.п. I>Я указал 4 обязательных пункта, которые нужны для внятного приложения. Отображаемый в память файл не проходит под п1, 2 и 3. п3 вместе с п1 вызывает серьезные сомнения, поскольку no-SQL не могут дать тех гарантий, что дает SQL DB. п2 и п4 — противоречие, не то файл смаппить, не то Redis взять
Последний раз поясняю банальные истины: это всё разные инструменты для разных задач. Т.е. в зависимости от особенностей задачи я могу взять:
1. sqlite (Postgresql для сетевого случая)
2. LevelDB (Redis для сетевого случая)
3. Отображаемый на структуру в памяти файл (связанный скажем через MPI для сетевого случая).
И каждый из них будет оптимальнее в своей области применения.
_>>Что касается данного примера, то очевидно, что для сохранения данных в файл без оверхеда никакое метапрограммирование не требуется. ))) I>А как ты собираешься типизировать запросы ? Они то никуда не деваются. Или ты намекаешь, что раз сторадж сменился, то не худо бы код на sqlpp переписать ?
В случае отображения файла на фиксированную структуру очевидно, что никакие запросы не требуются в принципе.
Здравствуйте, Ikemefula, Вы писали:
_>>Не надо мне какие-то исходники показывать. Покажи просто один linq запрос и генерируемые из него оптимизированные sql строки под разные СУБД. Всё. Такая простая вещь будет 100% доказательством. Однако что-то никто не может показать ни единого примера уже сколько дней после "анонса" здесь этой чудесной возможности. I>Уже показали.
Ну давай ссылку на соответствующее сообщение в данной теме. Мало ли, вдруг это не твои обычные отмазки, а действительно было и я пропустил. Но что-то я сильно сомневаюсь. )))
Здравствуйте, Danchik, Вы писали:
_>>Не надо мне какие-то исходники показывать. Покажи просто один linq запрос и генерируемые из него оптимизированные sql строки под разные СУБД. Всё. Такая простая вещь будет 100% доказательством. Однако что-то никто не может показать ни единого примера уже сколько дней после "анонса" здесь этой чудесной возможности. D>Вот, я делал пулл реквест, он еще не принят, но суть того что можна сотворить с SQL, понять сможешь из линка ниже D>http://rsdn.ru/forum/prj.rfd/6345934.flat
Ну что же. Для начала сразу хочу поставить тебе "большой плюс", потому что пока что это единственный пример хоть какой-то оптимизации в данной теме. Остальные не смогли показать даже этого. Но к сожалению данная оптимизация не относится к требуемому (прочитай хотя бы цитату выше, на которую ты отвечал), т.к. в ней нет никакой оптимизации под конкретную СУБД. Это пример из той же серии, что и убирание лишних полей из изначально криво записанных запросов и в приличном коде просто не требуется. Т.е. актуальная разве что для начинающих специалистов вещь, а профессионалам наоборот мешающая. В отличие от анонсированной в данной теме некой умной оптимизации под конкретную СУБД. Вот такое действительно пригодилось бы всем, но судя по отсутствию конкретных примеров данная возможность — это всего лишь миф.
Здравствуйте, alex_public, Вы писали: _>Т.е. изначальный тезис о том, что "главное узкое место — это транспорт данных между клиентом и сервером (HTTP)" уже не вспоминаем... Это правильно.)))
Почему не вспоминаем??? Просто расшивку этого узкого места на диаграмме деплоймента не увидишь. Её видно при анализе HTTP запросов и ответов: conditional get, expiration:never, нормализация порядка аргументов путём 302 Found видны только при анализе трафика на тестовых запросах.
_>Да, безусловно главная проблема масштабирования это СУБД. Собственно потому и расплодились не так давно nosql решения, что sql сервера стали частенько достигать пределов вертикально масштабирования (ну во всяком случае за вменяемые деньги), а на автоматическое горизонтальное они не способны.
NoSQL в большинстве случаев это не решение вообще. Это подмена требований к задаче, чтобы делать не то, чего хотелось, а то, чего удалось.
А если NoSQL не устраивает (например, требования к consistency пожёстче, чем у фоточек с лайками), то надо таки задуряться тем, чтобы писать хорошие SQL запросы.
_>Но это совершенно не означает, что теоретическая возможность нормального горизонтального масштабирования кода "приложения" (хотя странно называть этим громким словом тонкий слой скриптов между http демоном и sql сервером) даёт право на выкидывание денег на соответствующие сервера впустую (на выполнение ненужной задачи, которая существует только из-за кривых инструментов программистов).
Я не знаю, каким инструментом вы измеряете толщину этого слоя. В хорошо написанных приложениях эта толщина вполне себе велика — потому что унести на клиента всю логику нельзя по соображениям целостности и безопасности, а в RDBMS — по соображениям производительности.
А про "выкидывание впустую" вы промахнулись — это скорее о затратах на ручную полировку SQL запросов, которая нужна только из-за кривых инструментов программистов.
_>Давай всё же определимся о чём конкретно идёт речь. А то в данной дискуссии похоже постоянно путаются три разные вещи: _>1. Генерация sql кода с синтаксисом соответствующим конкретной СУБД. Имеется везде (и linq ORM и в том C++ решение на шаблонах и ещё много где).
Нет, в шаблонном решении на С++ эта задача решена на твёрдую три с минусом:
А. Нет возможности переструктурировать запрос. Для того, чтобы корректно собрать SQL Statement для всяких разных условий, надо не строки клеить, а анализировать дерево выражений. Пример только что приводили http://rsdn.ru/forum/prj.rfd/6345934.flat
— там исчезают лишние join вообще. Одно и то же linq-выражение типа where x.Contains(o.id) должно превращаться в зависимости от диалекта и переданных параметров либо в where o.id = @x1 or o.id = @x2 or o.id = @x2, либо в where o.id in (@x1, @x2, @x3), либо в inner join f.tableValue(@x1, @x2, @x3) x on o.id = x.id
Б. Нет возможности подключать новые провайдеры, которые бы даже в примитивном случая заменяли бы одн на другое. Поскольку весь анализ "дерева выражений" делается в компайл-тайм, то и все оптимизации делаются в компайл тайм. Единственный способ научить приложение генерировать все три вида строк — это вставить в каждый вызов SQL if-statement, проверяющий "если SQLite — то так, если SQLServer 2012 — то так, если SQL Server 2005 — то вот эдак". И даже после этого прикрутка Postgres потребует перекомпиляции.
_>2. Частичная оптимизация изначально криво записанных запросов (вне зависимости от вида СУБД). Никчемная возможность, полезная разве что совсем новичкам, а профессионалам только мешающая (см. пример тех же SO). Нигде кроме Linq не видел (ну MS славится своими Визардами и т.п. игрушками для снижения порога входа, правда следствием становится сплошной индусо-код) и надеюсь не увидеть в будущем.
Это вы сами себе придумали глупую мысль про изначально криво написанные запросы. В реальной жизни стоит задача декомпозировать выражения. Это означает, что возможности "некриво" написать запрос у вас нет. А есть только
public double GetTotalComissionsAmount(IQueryable<Orders> orders, Employee salesManager);. При этом она описана в одном модуле, разработанном и поддерживаемом командой А. А используется она в десятке других модулей, разработанных и поддерживаемых командами Б, В и Г. И в неё передаются самые разные виды аргументов — где-то запрос вида from o in Orders where o.Date > startDate and o.Date <= endDate; где-то — запрос вида from o in Orders join it in db.OrderItems on o.id equals it.OrderId where it.ProductId = product select o; и так далее.
Окончательный SQL собирается там, где он будет использован. Нет никакого "изначально кривого" кода, который мог бы соптимизировать какой-то профи. Ну, если только этот профи не готов заменить лично собой команды А, Б, В и Г и переписать весь модульный код в монолитную массу, вносить исправления в которую может только он.
_>3. Умная оптимизация запросов с учётом особенностей конкретной СУБД. Вот такое действительно было бы очень интересно. И т.к. подобного точно нет в обсуждаемом C++ решение или тем более голых строках, то это реально могло бы подтвердить тезис о возможности Linq формировать более оптимальные запросы. Только вот не смотря на анонс существования данной возможности в Linq ORM ни единого (!) примера, подтверждающего это на практике, пока так и не было представлено. Так что данную возможность мы пока что считаем мифом.
Для начала я рекомендую ознакомиться с тем, сколькими способами Skip().Take() конвертируется в SQL. Это не синтаксис, это вопросы оптимизации с учётом особенностей конкретной СУБД.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Последний раз поясняю банальные истины: это всё разные инструменты для разных задач. Т.е. в зависимости от особенностей задачи я могу взять:
Для каких разных ? Я тебе __одну__ задачу показал, в ней 4 пункта и они обязательны. Ты же снова хочешь спрыгнуть на чтото своё.
I>>А как ты собираешься типизировать запросы ? Они то никуда не деваются. Или ты намекаешь, что раз сторадж сменился, то не худо бы код на sqlpp переписать ?
_>В случае отображения файла на фиксированную структуру очевидно, что никакие запросы не требуются в принципе.
Вот чудо !. Вот пример — надо найти все проводки по всем юзерам за весь период времени которые удовлетворяют определенному фильтру. Наверное ты собираешься гигабайты дисковой памяти прокачивать через оперативу ?
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Они были выполнены для вполне стандартных условий. Так вот там были накладные расходы в 500%! Т.е. полное противоречие твоей первой фразе — время запроса не сильно больше, а наоборот сильно меньше накладных расходов. G>>Где ты видел 500% ? Это твои больные фантазии.
_>Вот прямо здесь http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html в тесте "Simple TOP 10 query" EF показывает такие феерические результаты.
На самом деле многое зависит от тестов при инициализации БД (Configuration.AutoDetectChangesEnabled = false,Database.SetInitializer<Model1>(null))
, скорости компиляции первого запроса параметров которое может соизмеримо со временем теста, Метод AsNoTracking . Я тебе показывал примеры где автокомпиляции запросов не будет итд.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, gandjustas, Вы писали:
_>>>Они были выполнены для вполне стандартных условий. Так вот там были накладные расходы в 500%! Т.е. полное противоречие твоей первой фразе — время запроса не сильно больше, а наоборот сильно меньше накладных расходов. G>>Где ты видел 500% ? Это твои больные фантазии.
_>Вот прямо здесь http://liiw.blogspot.ru/2015/03/performance-of-linq-to-db-vs-entity.html в тесте "Simple TOP 10 query" EF показывает такие феерические результаты.
А при чем тут EF? Ты на linq2db смотри, он пока самый быстрый в этом забеге.
И не забывай про абсолютные цифры — это микросекунды. Выиграв даже 700 мкс на запрос ни время ответа, ни пропускная способность не изменится от слова вообще.
Так что проблема исключительно у тебя в голове.
G>>Условия в тестах вовсе не стандартные. Стандартные условия для БД — данные не находятся в памяти, их надо поднимать с диска. Именно под такой сценарий проектируются РСУБД. Для веба это зачастую верное предположение. G>>А в тестах на быстродействие Linq наоборот пытаются воздействие базы свести к минимуму — берут небольшие БД, повторяют одинаковые запросы много раз.
_>Ну так кто бы спорил, что если обслуживать исключительно запросы со временем исполнения в секунду и больше, то тормоза Linq даже в лупу не увидишь. Только вот что-то людям оказывается больше нужны совсем другие запросы (смотри тот же SO).
Еще раз посмотри ссылку которую ты привел. Время обработки linq измеряется несколькими миллисекундами, а то и долями миллисекунд. Время выполнения запроса БД — несколько миллисекунд или несколько десятков. linq составляет не более 10% от времени запроса. То есть 10% — максимум что ты сможешь выиграть со всеми приседаниями.
В SO не используют linq по историческим причинам. Они отказались от linq2sql из-за багов в провайдере. Других провайдеров на тот момент просто не было.
Сейчас они бы спокойно могли использовать linq2db, но у них уже есть своя либа на эту тему.
_>>>Канал будет узким местом только при особой криворукости программистов, запрашивающих гораздо больше данных чем надо (пользователю то на страницу почти никогда не надо выдавать тысячи строк). _>>>Хотя... В этой темке вроде как сообщили, что SQL Server научился командам OFFSET и т.п. только в 2012-ом году. При такой убогости конечно можно и канал занять. ))) G>> Ты очередной раз расписался в незнании SQL. С 2008 года можно было через row_count() сделать постраничное разбиение, оно работает также как offset. G>>Примерно в то же время появился linq, который для .Top и .Skip функций генерировал корректный код.
_>Не в незнание SQL, а в незнание одной убогой СУБД под названием SQL Server, на знание которой я никогда и не претендовал (даже близко не видел и не планирую).
Да ты и другие базы не знаешь так же, как SQL Server.
Кстати убогий SQL Server выбился в лидеры по версии gartner. Из ты тоже убогими назовешь?
_>Ну и даже если с 2008-го года существовал некий кривой костыль для данной функциональности (который они заменили на приличный синтаксис только в 2012-ом), то это всё равно смешно, т.к. с нормальными СУБД люди пользуются (и с нормальным синтаксисом) данной функциональностью уже не первое десятилетие.
С чего ты взял что это костыль?
_>Да, но я теперь больше понимаю почему дотнетчики так фанатеют от различных вариаций linq2database (буду так называть их все вместе, чтобы не было путаницы с одной конкретной). Многие из них обречены на работу с SQL Server, а похоже что писать для него чистый SQL крайне печально. Во всяком случае было ещё совсем не давно. )))
С чего твой больной мозг решил что написание SQL для других БД кардинально отличается?
G>>А какое "практическое подтверждение" ты хочешь увидеть? Тебе уже написали много людей, которые умнее тебя и имеют больше опыта. Я привел тебе пример из поста, ты все равно не веришь. Если ты поищешь по этому форуму, то увидишь посты авторов rsdn о быстродействии linq в сравнении с рукопашными запросами. _>Это которые с хранимок перелезали? ) Ну да, ну да, смешно. )))
А чем хранимки принципиально отличаются от рукопашных запросов с точки зрения скорости работы?
_>А подтверждение нужно очень простое. Я уже не раз писал. Пример linq запроса и примеры оптимизированного им под конкретные СУБД sql кода. Что может быть проще? Но пока в теме не было ни одного такого примера. Хотя фанаты анонсировали именно такую возможность, как главное преимущество.
Я не знаю о каком оптимизированном коде идет речь. Я тебе уже многократно писал, что linq генерирует разные запросы для разного сочетания параметров и проекций. Именно это и дает максимальное быстродействие.
Человек так не может — слишком сложно поддерживать все запросы. Никаких магических оптимизаций нет.
_>Никто тут не говорил, что данная библиотечка умеет заниматься оптимизацией SQL запросов. Точнее теоретически это конечно же возможно, но в данной реализации отсутствует (и вряд ли будет добавляться за ненадобностью).
Прости, от смеха чуть не упал. После этого ты имеешь что-то против EF?
_>>>С какой это стати рассматривать аналогом linq запроса хранимку, а не нормальный запрос? G>>Ты опять показываешь профанизм, бросай. В чем отличие "хранимки" от "нормального запроса" в этом случае? Даю подсказку — ни в чем, абсолютно одинаковое поведение.
_>Нормальный запрос — это sql строка, передаваемая некой функции типа sql_execute(""). Так вот я с большим удовольствием посмотрю на твой код (на том же C#) создания этой sql строки с использованием той же самой C# переменной dateTime, как в твоём linq варианте. _>Подсказка-анонс: твой неоптимизированный sql вариант (с которым ты вроде как борешься и побеждаешь его с помощью linq) будет намного длиннее и неудобнее простейшего оптимизированного и соответственно встретится только у очень странных людей.
Ты сейчас какой-то бред написал, я даже не понял что ты имеешь ввиду. Можешь код показать?
_>Да, соответствие между SQL и Linq не полное. Это может быть как плюсом (где-то синтаксис выразительнее) так и минусом (программист не полностью контролирует результат, что как раз не нравилось команде SO). Кстати тут наблюдается очень близкая аналогия с тем же сборщиком мусора. Новичку на простом проекте это помогает, а профессионалом в сложных задачах только мешает.
Никакой аналогии не наблюдается, это голоса в твоей голове.
Отсутствие декомпозиции плюсом не является и являться не может. Оно сильно количество запросов, которые можно написать. Из-за этого нет возможности написать оптимальные запросы под каждый сценарий. Поэтому linq рулит. Не магическими оптимизациями, которые тебе мерещатся, а банальной генерацией запросов.
_>>>Ты точно смотрел на картинку с их архитектурой? ) По твоему там 98% машин с windows? G>>Я про windows писал? *nix они используют по одной причине — "better money allocation". К вопросам разработки оно не относится. _>Ну во-первых я писал в том числе и про windows. То, что ты отвечаешь только на удобную тебе часть моей фразы, для меня не новость. Во-вторых изменение платформы вполне себе влияет и на разработку, т.к. под линухом там запускают совсем не .net код.
Насколько я понял все что обрабатывает запросы и написано в SO работает под windows.
_>>>До тебя так и не дошло? ) Проблема не в исходниках, а в сборке. Там же не просто обычный пример на C#, который я могу собрать в командной строке. G>>Давай я тебе дам виртуалку с SQL Server и VS, а ты все сделаешь, ок? _>Я же сказал, с C#, SQL Server и т.п. кактусами возитесь сами. У меня нет времени разбираться в их кривых костылях. Я готов повозиться только с C++ аналогом. Плюс, чтобы провести тесты на одной машине я готов запустить подготовленный мне пакет. )
От тебя требуется только написать и отладить код, который с SQL Server работет и выложить на github.
Найдутся люди, которые достаточно хорошо знают и C# и C++, чтобы провести замеры.
Так ты сделаешь? Виртуалку с уже установленным SQL Server и VS я дам.
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Danchik, Вы писали:
_>>>Не надо мне какие-то исходники показывать. Покажи просто один linq запрос и генерируемые из него оптимизированные sql строки под разные СУБД. Всё. Такая простая вещь будет 100% доказательством. Однако что-то никто не может показать ни единого примера уже сколько дней после "анонса" здесь этой чудесной возможности. D>>Вот, я делал пулл реквест, он еще не принят, но суть того что можна сотворить с SQL, понять сможешь из линка ниже D>>http://rsdn.ru/forum/prj.rfd/6345934.flat
_>Ну что же. Для начала сразу хочу поставить тебе "большой плюс", потому что пока что это единственный пример хоть какой-то оптимизации в данной теме. Остальные не смогли показать даже этого. Но к сожалению данная оптимизация не относится к требуемому (прочитай хотя бы цитату выше, на которую ты отвечал), т.к. в ней нет никакой оптимизации под конкретную СУБД. Это пример из той же серии, что и убирание лишних полей из изначально криво записанных запросов и в приличном коде просто не требуется. Т.е. актуальная разве что для начинающих специалистов вещь, а профессионалам наоборот мешающая. В отличие от анонсированной в данной теме некой умной оптимизации под конкретную СУБД. Вот такое действительно пригодилось бы всем, но судя по отсутствию конкретных примеров данная возможность — это всего лишь миф.
Не передергивай, я тебе показал что оптимизации есть. Я написал ее в коде который общий для ВСЕХ SQL драйверов. Никто мне не мешал закинуть это только для Oracle
Такие же оптимизаторы есть под каждую базу, и там дерево выражений может существенно изменится. Беглый взгляд по сурцам показывает что сейчас отличия незначительны, просто более тонко используют служебные функции, НО они (оптимизации) возможны. Есть идеи — допиливай.
И никто не будет для тебя подымать environment с разными серверами чтобы ты наконецто снизошел до понимания.
Тебе показали КАК соптимизировало, сколько было джоинов и на что джоинов, и сколько стало — декомпозиция запросов в чистом виде.
За 8 лет процент .NET кода изменился со 100% до 98%, причем в неважных частях, это значит "неуклонно падает". Не занимайся примитивной демагогией.
