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

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

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

LP>>>Помню, интегрировался я с этим г-ном, долго и упорно. Сотни каких-то непонятных таблиц с непонятными именами... Так вот, кто это оказывается написал..

S>>Потому, что у тебя не было Code First и Linq to EF на примере 1С версии 8.3 часть II

D>CodeFirst тут не увидел. Базу что-ли создаешь?
D>Опять не смог понять твой русский код. Не читается оно и все тут.
D>Ты c таким кодом попробуй в StackOverflow что-то закинуть. А тут и так болшая часть не переваривает, одно это чего стоит: РасширениеДляГуид

Нет там создается CodeFirst к базе данных 1С. Ну писалось то для 1С ников

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

V>>Несколько раз мне приходилось генерить ключи самому.
V>>"Приходилось" означает, что другие решения были намного дороже.
S>Ок, давайте теперь поговорим о нужде знать ID ещё до вставки.

Закинуть за раз некий развесистый граф данных из многих таблиц.
Когда идёт большой трафик таких событий, то и выхода другого часто нет.
В этом случае клиент запрашивает сначала целый диапазон ID (целый участок "свободной памяти"), а потом пихает эти ID-шки.


S>Я видел решения, которые устроены примерно так, как ты описал (хотя решительно не понимаю, как там можно оперативно возвращать неиспользованные ключи, не встревая в 2phase commit и прочий хардкор).

Оно принципиально хорошо живёт только в случае выделенного сервера приложений, т.к. такой временный агрегат для хранение еще не слитых ID должен быть (1) максимально легковесным и (2) иметь не реляционную природу, а иерархическую/кластерную. Обычно "оно" представляет из себя дерево тех самых кластеров (двоичное дерево для многих популярных алгоримов управления памятью), где к каждому кластеру привязан тот самый вязанный список свободной памяти, которую пока невозможно слить в непрерывные участки по основанию логарифма кластера. Инфа о самих кластерах может сохраняться в таблицах, но каждый новый кластер, взятый/порождённый для раздачи ID, предварительно инициализируется в оперативной памяти, т.е. в нём ищутся те самые свободные участки (если есть).


S>В тех случаях, когда я их видел, "необходимость" была продиктована достаточно искусственными причинами.

Какими например?

У меня-то причина более чем на поверхности — взять даже банальный master-slave.
Я хорошо представляю себе как закинуть в одной операции одну строку из master и к ней несколько из slave без заведомого знания про ID master-а, но плохо представляю как закинуть за раз несколько строк master-a с соотв. привязанными slave без предварительного знания ID master-ов.

Более того, в первом случае придётся еще озаботиться ожиданием ответа из вызова серверной процедуры, а в трехзвенке (не HTTP, а в классическом сервере приложений) всё-таки намного удобней иметь АПИ в котором львиная доля трафика представляет из себя просто обмен асинхронными сообщениями. Т.е. отправили данные на сервер, но локально имеем возможность продолжать что-то с данными делать. Через некоторое время асинхронно придёт оповещение об успешности/неуспешности операции, но в этот промежуток времени на клиенте нет надобности ждать возвращённый в синхронной манере ID.

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

V>Закинуть за раз некий развесистый граф данных из многих таблиц.
Непонятно. Без конкретного примера — ничего непонятно.

V>Когда идёт большой трафик таких событий, то и выхода другого часто нет.
V>В этом случае клиент запрашивает сначала целый диапазон ID (целый участок "свободной памяти"), а потом пихает эти ID-шки.
Это всё от убогости.

V>Оно принципиально хорошо живёт только в случае выделенного сервера приложений, т.к. такой временный агрегат для хранение еще не слитых ID должен быть (1) максимально легковесным и (2) иметь не реляционную природу, а иерархическую/кластерную. Обычно "оно" представляет из себя дерево тех самых кластеров (двоичное дерево для многих популярных алгоримов управления памятью), где к каждому кластеру привязан тот самый вязанный список свободной памяти, которую пока невозможно слить в непрерывные участки по основанию логарифма кластера. Инфа о самих кластерах может сохраняться в таблицах, но каждый новый кластер, взятый/порождённый для раздачи ID, предварительно инициализируется в оперативной памяти, т.е. в нём ищутся те самые свободные участки (если есть).
Всё равно непонятно. Вот я начал вставлять с использованием свежевыбранного ID. При этом он уже из "кластера" ушёл — иначе в параллельной транзакции его схватит кто-то ещё.
Тут пропала связь с RDBMS. Как мне понять, транзакция закоммитилась или нет? Всё, ID утёк.
Восстановление состояния каунтеров потребует перевода всей системы в readonly и переинвентаризации идентификаторов.
Альтернатива: забить на "дырки", как и делают все СУБД.

S>>В тех случаях, когда я их видел, "необходимость" была продиктована достаточно искусственными причинами.
V>Какими например?
V>У меня-то причина более чем на поверхности — взять даже банальный master-slave.
Ну вот например такой master-slave.
V>Я хорошо представляю себе как закинуть в одной операции одну строку из master и к ней несколько из slave без заведомого знания про ID master-а, но плохо представляю как закинуть за раз несколько строк master-a с соотв. привязанными slave без предварительного знания ID master-ов.
А что тут представлять???

begin tran
insert into master (name) values ('Первыйнах')
set @ID1 = SCOPE_IDENTITY()
insert into slave(masterId, Name) values (@ID1, 'Первый-1')
insert into slave(masterId, Name) values (@ID1, 'Первый-2')
insert into master (name) values ('Между первой и второй перерыва вовсе нет')
set @ID2 = SCOPE_IDENTITY()
insert into slave(masterId, Name) values (@ID2, 'Второй-1')
insert into slave(masterId, Name) values (@ID2, 'Второй-2')
commit tran

Это — пример на технологиях каменного века. С тех пор придумали output clause, которое позволяет делать и более впечатляющие трюки.
V>Более того, в первом случае придётся еще озаботиться ожиданием ответа из вызова серверной процедуры,
Зачем ждать-то? fire and forget.
V> а в трехзвенке (не HTTP, а в классическом сервере приложений) всё-таки намного удобней иметь АПИ в котором львиная доля трафика представляет из себя просто обмен асинхронными сообщениями. Т.е. отправили данные на сервер, но локально имеем возможность продолжать что-то с данными делать. Через некоторое время асинхронно придёт оповещение об успешности/неуспешности операции, но в этот промежуток времени на клиенте нет надобности ждать возвращённый в синхронной манере ID.
Отож. Всё так. И по-прежнему клиенту не обязательно знать идентификаторы заранее. Никаких тебе заморочек с над-реляционными кластерами.

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

S>Это да. В реляционной модели (для работы с которой и проектировался линк) нет понятия "предыдущей строки". Кортежи предполагаются независимыми, поэтому готовых методов работы нету.

Поэтому я и говорю, что данный подход работы с коллекциями является далёким от идеала. Я про это писал ещё при появление linq, когда с его помощью работали только с коллекциями, а не с БД. Для реляционных СУБД ситуация чуть лучше, но только потому, что эти СУБД предоставляют интерфейс на базе SQL, т.е. с теми же самыми ограничениями. Вот если бы можно было задавать запросы на императивном языке (вариант типа декларации процедуры и потом её запуска естественно не рассматриваем), то linq уже пролетал бы и с СУБД...

Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?

S>А вот на linq на самом деле ничего военного нет — он же часть языка общего назначения. Я могу легко определить функцию
S>

S>public IEnumerable<CurrentPrev<T, T>> PairScan(this IEnumerable<T> source)
S>{
S>   var e = source.GetEnumerator();
S>   if (!e.MoveNext())
S>     yield break;
S>   var prev = e.Current;
S>   while(e.MoveNext())
S>   {
S>     yield return new CurrentPrev(){Current = e.Current; Previous = prev};
S>     prev = e.Current;
S>   }
S>}
S>

S>После этого задачка становится тривиальной.
S>

S>var q = from s in source.PairScan() where s.Previous.Length > MinLength && s.Current.Length > MinLength select (здесь то выражение, которое там от чего-то зависит)
S>

Хы, ты серьёзно? ))) Ты представляешь себе эффективность подобного кода? Если что, в тупом императивном варианте это всё считалось в один проход по одной переменной цикла.

S>В нормальных СУБД примерно то же строится при помощи table-valued function, и весь ужос-ужос тоже прячется под капот, позволяя поверх него наворачивать дополнительные условия.

Что-то сомневаюсь, что внутри СУБД оно работает вот так вот. Иначе бы это дико тормозило.

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

IT>ЗЫ. Сам по себе трёп linq vs императив считаю бестолковым и местами туповатым, примерно как FP vs OOP, отвёртка против молотка. Оно не должно быть не одно против другого, оно должно быть вместе и дополнять.

Возможно. Но в таком случае ты значит тоже считаешь, что предоставляемый реляционными СУБД интерфейс на базе SQL крайне далёк от идеала...

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

_>Возможно. Но в таком случае ты значит тоже считаешь, что предоставляемый реляционными СУБД интерфейс на базе SQL крайне далёк от идеала...

Ещё мне кажется, что и жизнь на базе кислорода тоже крайне далека от идела. Но так получилось. Да и с альтернативами оно как-то не очень.

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

_>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
Нет, не смотрел. А там есть какой-то язык запросов?
_>Хы, ты серьёзно? ))) Ты представляешь себе эффективность подобного кода?
Конечно представляю.
_>Если что, в тупом императивном варианте это всё считалось в один проход по одной переменной цикла.
И здесь тоже — в один проход.
S>>В нормальных СУБД примерно то же строится при помощи table-valued function, и весь ужос-ужос тоже прячется под капот, позволяя поверх него наворачивать дополнительные условия.
_>Что-то сомневаюсь, что внутри СУБД оно работает вот так вот. Иначе бы это дико тормозило.
Оптимизатор внутри промышленной СУБД умеет превращать "join c лагом" в однократное сканирование.

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

_>Поэтому я и говорю, что данный подход работы с коллекциями является далёким от идеала.
Ничего ближе пока нет...

_> Я про это писал ещё при появление linq, когда с его помощью работали только с коллекциями, а не с БД. Для реляционных СУБД ситуация чуть лучше, но только потому, что эти СУБД предоставляют интерфейс на базе SQL, т.е. с теми же самыми ограничениями.
Это не ограничения, а абстракция, которая позволяет отделить логику работы с конкретной коллекцией от прикладного кода. И вот это практически идеал.
Это как раз то, что позволило реляционным базам стать такими эффективными и при этом универсальными.

_>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
Полная печаль.

mongoCollection.find({'keyField':value}).sort({'sortField':1})

Очевидно, что никакого контроля за тем, что ты написал в строке нет и это полная дичь, даже по сравнению с любой более-менее нормальной ORM, не говоря уже о линке.
Она начиналась как хранилище JSON-а для JS(node js), динамического и слаботипизированного. И это торчит из всех щелей... Самое смешное, что для нее теперь пишут ODM-ы — Object Document Mapper-ы. =)
Ирония в том, что изначально возможность хранить объекты как есть продавалась как killing feature этой базы.... ну и вот.

_>Хы, ты серьёзно? ))) Ты представляешь себе эффективность подобного кода? Если что, в тупом императивном варианте это всё считалось в один проход по одной переменной цикла.
Здесь тоже один проход.

_>Что-то сомневаюсь, что внутри СУБД оно работает вот так вот. Иначе бы это дико тормозило.
Это то, о чем я присал выше. благодаря такой абстракции, у СУБД очень богатые возможности по оптимизации, чем она и пользуется.

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

_>>Возможно. Но в таком случае ты значит тоже считаешь, что предоставляемый реляционными СУБД интерфейс на базе SQL крайне далёк от идеала...
IT>Ещё мне кажется, что и жизнь на базе кислорода тоже крайне далека от идела. Но так получилось. Да и с альтернативами оно как-то не очень.

Ну почему же, различных nosql систем сейчас множество, популярность их только растёт и у каждой из них обычно своя вариация на тему запросов (в том числе и частенько в виде императивного языка).

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

_>>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
S>Нет, не смотрел. А там есть какой-то язык запросов?

Конечно.

_>>Хы, ты серьёзно? ))) Ты представляешь себе эффективность подобного кода?
S>Конечно представляю.

Точно? Лично я думаю, что этот код будет в разы медленнее тупого императивного аналога.

_>>Если что, в тупом императивном варианте это всё считалось в один проход по одной переменной цикла.
S>И здесь тоже — в один проход.

Тьфу, что-то я с этими разговорами про БД (где как раз актуально количество проходов) совсем заговорился и криво сформулировал свою мысль. В данном случае проблемой конечно же будет дикое количество переключений сопрограмм и ненужных копирований.

S>>>В нормальных СУБД примерно то же строится при помощи table-valued function, и весь ужос-ужос тоже прячется под капот, позволяя поверх него наворачивать дополнительные условия.
_>>Что-то сомневаюсь, что внутри СУБД оно работает вот так вот. Иначе бы это дико тормозило.
S>Оптимизатор внутри промышленной СУБД умеет превращать "join c лагом" в однократное сканирование.

Причём тут join (да ещё и с самим собой)? В части современных РСУБД данная проблема решается просто через функцию lag (ну или lead — опять же даже в наличие двух отдельных функций чувствуется костыльность этого решения). Так вот я крайне сомневаюсь, что её внутренняя реализация выглядит как превращение таблицы в набор пар, как в твоём примере. ))) Наверняка там простейшее прямое обращение к данным, в классическом императивном стиле. Собственно иначе и быть не может (и даже не из-за производительности), т.к. lag можно задать динамическое смещение (как и в императивном коде).

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

_>>Поэтому я и говорю, что данный подход работы с коллекциями является далёким от идеала.
IB>Ничего ближе пока нет...

Ну как же, если мы говорим про работу с коллекциями (а не про СУБД), то обычный императивный код (типа for() ... ) никуда не делся. И при этом он по прежнему является как наиболее обобщённым, так и наиболее производительным.

_>> Я про это писал ещё при появление linq, когда с его помощью работали только с коллекциями, а не с БД. Для реляционных СУБД ситуация чуть лучше, но только потому, что эти СУБД предоставляют интерфейс на базе SQL, т.е. с теми же самыми ограничениями.
IB>Это не ограничения, а абстракция, которая позволяет отделить логику работы с конкретной коллекцией от прикладного кода. И вот это практически идеал.
IB>Это как раз то, что позволило реляционным базам стать такими эффективными и при этом универсальными.

Конечно. Но эта абстракция существенно ограничена. Причём это было вполне логично с учётом изначального её позиционирования. А вот для её дальнейшего применение (так уж исторически сложилось) эти ограничения были уже не совсем подходящими...

_>>Кстати, ты в курсе языка запросов в MongoDB? Что скажешь про его возможность работы с произвольным кодом?
IB>Полная печаль.
IB>

IB>mongoCollection.find({'keyField':value}).sort({'sortField':1})
IB>

IB>Очевидно, что никакого контроля за тем, что ты написал в строке нет и это полная дичь, даже по сравнению с любой более-менее нормальной ORM, не говоря уже о линке.

А причём тут вообще ORM или LINQ? Мы говорим о сравнение с SQL. Создать типизированный DSL можно для любого промежуточного языка. Вопрос в том, какие возможности представляет этот промежуточный язык, т.к. данный DSL очевидно будет им ограничен.

Далее, ты привёл очень скучный пример, очевидно транслирующийся в SQL — правильнее было рассмотреть то, что невозможно на SQL. И я говорю даже не о врождённых преимуществах таких СУБД, типа MapReduce, а совсем о другом, что хорошо видно в моей цитате выше. О возможности задания внутри запроса произвольного императивного кода (банальная JS-лямбда).

_>>Что-то сомневаюсь, что внутри СУБД оно работает вот так вот. Иначе бы это дико тормозило.
IB>Это то, о чем я присал выше. благодаря такой абстракции, у СУБД очень богатые возможности по оптимизации, чем она и пользуется.

Я думаю что в данном конкретном случае никакой оптимизации и абстракций нет, потому как оно и так просто нормально работает.

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

_>Ну как же, если мы говорим про работу с коллекциями (а не про СУБД), то обычный императивный код (типа for() ... ) никуда не делся. И при этом он по прежнему является как наиболее обобщённым, так и наиболее производительным.
Конечно же нет. Для обобщенного императивный for содержит слишком много деталей реализации, и это мешает быть ему производительным на не тривиальных коллекциях.

_>Конечно. Но эта абстракция существенно ограничена.
Наоборот, она развязывает руки и позволяет отделить мух от котлет. В прикладном коде описать желаемый результат, вместо конкретного алгоритма обхода, а уже самой коллекции решить как лучше с ней работать. Там вполне может быть так нежно любимый императивный for. Как совершенно верно заметил IT, нет смысла противопоставлять одно другому — оно все отлично работает вместе.

_>А причём тут вообще ORM или LINQ? Мы говорим о сравнение с SQL. Создать типизированный DSL можно для любого промежуточного языка. Вопрос в том, какие возможности представляет этот промежуточный язык, т.к. данный DSL очевидно будет им ограничен.
Если сравнивать с SQL, то даже по этому скучному примеру видно, что Монга всасывает. Точнее, пример можно немного расширить, для наглядности:
mongoCollection.find({'keyField':value, $or:[{'keyField2':value}}).sort({'sortField':1})
особенно феерично выглядит update, пример прям из документации — collection.update({_id:"123"}, {$set: {author:"Jessica"}});
Они не смогли придумать язык, даже в рамках динамического и не типизированного JS, который бы позволил обойтись без строковых команд. В итоге получается дичайший микс кода в коде и кода в строке. Я понимаю, JSON под ногами болтается, но все же... Это к вопросу именно о языке, а не о платформе в целом.

_>Далее, ты привёл очень скучный пример, очевидно транслирующийся в SQL — правильнее было рассмотреть то, что невозможно на SQL. И я говорю даже не о врождённых преимуществах таких СУБД, типа MapReduce, а совсем о другом, что хорошо видно в моей цитате выше. О возможности задания внутри запроса произвольного императивного кода (банальная JS-лямбда).
Именно язык запросов монги тоже лямбд не позволяет. лямбду можно впихнуть из языка, но тогда логичнее было бы сравнивать не с чистым SQL-ем, а с linq. И тут опять же я боюсь, что монга всосет, так как на линке и синтаксис чище и саму лямбду в ряде случаев можно раскрутить до SQL-я, что значительно повысит ее эффективность.

_>Я думаю что в данном конкретном случае никакой оптимизации и абстракций нет, потому как оно и так просто нормально работает.
В данном может быть и нет, а в целом — запросто.

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

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

_>>>Возможно. Но в таком случае ты значит тоже считаешь, что предоставляемый реляционными СУБД интерфейс на базе SQL крайне далёк от идеала...
IT>>Ещё мне кажется, что и жизнь на базе кислорода тоже крайне далека от идела. Но так получилось. Да и с альтернативами оно как-то не очень.

_>Ну почему же, различных nosql систем сейчас множество, популярность их только растёт и у каждой из них обычно своя вариация на тему запросов (в том числе и частенько в виде императивного языка).

Мы вроде как говорим о предоставляемом реляционными СУБД интерфейсе на базе SQL.

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

_>>Ну как же, если мы говорим про работу с коллекциями (а не про СУБД), то обычный императивный код (типа for() ... ) никуда не делся. И при этом он по прежнему является как наиболее обобщённым, так и наиболее производительным.
IB>Конечно же нет. Для обобщенного императивный for содержит слишком много деталей реализации, и это мешает быть ему производительным на не тривиальных коллекциях.

Ну если ты так считаешь, то конечно же легко сможешь привести хотя бы один пример, в котором работа с коллекциями на базе Linq будет более быстродействующей, чем произвольный императивный код? )

_>>Конечно. Но эта абстракция существенно ограничена.
IB>Наоборот, она развязывает руки и позволяет отделить мух от котлет. В прикладном коде описать желаемый результат, вместо конкретного алгоритма обхода, а уже самой коллекции решить как лучше с ней работать. Там вполне может быть так нежно любимый императивный for. Как совершенно верно заметил IT, нет смысла противопоставлять одно другому — оно все отлично работает вместе.

Ну если бы можно было описывать любые возможные результаты, то тогда конечно. Но это явно речь не про SQL.

_>>А причём тут вообще ORM или LINQ? Мы говорим о сравнение с SQL. Создать типизированный DSL можно для любого промежуточного языка. Вопрос в том, какие возможности представляет этот промежуточный язык, т.к. данный DSL очевидно будет им ограничен.
IB>Если сравнивать с SQL, то даже по этому скучному примеру видно, что Монга всасывает. Точнее, пример можно немного расширить, для наглядности:
IB>mongoCollection.find({'keyField':value, $or:[{'keyField2':value}}).sort({'sortField':1})
IB>особенно феерично выглядит update, пример прям из документации — collection.update({_id:"123"}, {$set: {author:"Jessica"}});
IB>Они не смогли придумать язык, даже в рамках динамического и не типизированного JS, который бы позволил обойтись без строковых команд. В итоге получается дичайший микс кода в коде и кода в строке. Я понимаю, JSON под ногами болтается, но все же... Это к вопросу именно о языке, а не о платформе в целом.

И как это всё влияет на возможности языка? Мы же обсуждаем именно их, а не внешнюю красоту (тем более, что сейчас многие предпочитаю прятать этот промежуточный язык за встраиваемыми DSL'ми).

_>>Далее, ты привёл очень скучный пример, очевидно транслирующийся в SQL — правильнее было рассмотреть то, что невозможно на SQL. И я говорю даже не о врождённых преимуществах таких СУБД, типа MapReduce, а совсем о другом, что хорошо видно в моей цитате выше. О возможности задания внутри запроса произвольного императивного кода (банальная JS-лямбда).
IB>Именно язык запросов монги тоже лямбд не позволяет. лямбду можно впихнуть из языка, но тогда логичнее было бы сравнивать не с чистым SQL-ем, а с linq. И тут опять же я боюсь, что монга всосет, так как на линке и синтаксис чище и саму лямбду в ряде случаев можно раскрутить до SQL-я, что значительно повысит ее эффективность.

Это не так. Произвольные функции можно задавать как в MapReduce, так и в выражение where. Собственно единственный пример в документации к where https://docs.mongodb.com/manual/reference/operator/query/where/ как раз это демонстрирует.

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

_>>Ну почему же, различных nosql систем сейчас множество, популярность их только растёт и у каждой из них обычно своя вариация на тему запросов (в том числе и частенько в виде императивного языка).
IT>Мы вроде как говорим о предоставляемом реляционными СУБД интерфейсе на базе SQL.

Не совсем. Мы обсуждаем чем бы таким более эффективным заменить SQL в реляционных СУБД. И в этом смысле вполне можно в качестве вдохновения полистать различные вариации реализации запросов во множестве популярных nosql СУБД.

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

_>Не совсем. Мы обсуждаем чем бы таким более эффективным заменить SQL в реляционных СУБД. И в этом смысле вполне можно в качестве вдохновения полистать различные вариации реализации запросов во множестве популярных nosql СУБД.

Видимо у меня проблемы с восприятием такой логики. Мы обсуждаем замену языка запросов в реляционных СУБД, поэтому давайте обсудим замену самих реляционных СУБД. Это как?

Здравствуйте, alex_public, Вы писали:
_>Конечно.
Ок, посмотрим при случае.
_>>>Хы, ты серьёзно? ))) Ты представляешь себе эффективность подобного кода?
S>>Конечно представляю.
_>Точно? Лично я думаю, что этот код будет в разы медленнее тупого императивного аналога.
_>Тьфу, что-то я с этими разговорами про БД (где как раз актуально количество проходов) совсем заговорился и криво сформулировал свою мысль. В данном случае проблемой конечно же будет дикое количество переключений сопрограмм и ненужных копирований.
Ух ты! Резкий поворот: только что мы говорили о выразительности и объёме кода, как вдруг перешли к производительности.
Да, это правда — в дотнете с оптимизацией всё не очень хорошо. Но в этом виноват не Linq — как раз он-то делает всё, что можно, чтобы помочь оптимизатору.
Основная затычка — невозможность инлайнить делегаты, в которые превращается код на linq to objects.
Если бы были инлайны — то и копирования можно было бы устранить, т.к. результирующий выхлоп был бы эквивалентен "тупому императивному аналогу".

S>>Оптимизатор внутри промышленной СУБД умеет превращать "join c лагом" в однократное сканирование.
_>Причём тут join (да ещё и с самим собой)?
При том, что это — единственный способ решить поставленную задачу на стандартном SQL без оконных функций.
_>В части современных РСУБД данная проблема решается просто через функцию lag (ну или lead — опять же даже в наличие двух отдельных функций чувствуется костыльность этого решения). Так вот я крайне сомневаюсь, что её внутренняя реализация выглядит как превращение таблицы в набор пар, как в твоём примере. )))
Ох-хо-хо. В некотором смысле, бессмысленно обсуждать схожесть реализации RDBMS с тем или иным кодом на языке общего назначения.
Даже самый тупой дотнетовый код превращает выражение вроде SalesQuotaHistory.SalesQuota в разыменование указателя со смещением.
А внутри RDBMS вместо двух команд ассемблера стоит вызов подпрограмм вроде RetrieveRecordFieldValue, которые анализируют заголовок записи совместно с метаданными таблицы и прочее.
Там же интерпретатор вообще.
С другой стороны, не стоит слишком сгущать краски с "набором пар". Если мы работаем со ссылочным типом, то размер одной пары — это ровно два указателя. Сам по себе код вот этого вот PairScan вполне может быть заинлайнен, получив ровно то же самое, что и в "тупом императивном аналоге", и все эти пары будут жить только в регистрах.

_>Наверняка там простейшее прямое обращение к данным, в классическом императивном стиле. Собственно иначе и быть не может (и даже не из-за производительности), т.к. lag можно задать динамическое смещение (как и в императивном коде).
Не всё так просто. С учётом того, что исполнительный механизм работает с "перечисляемыми" источниками, которые умеют делать только GetNext() (то есть эквивалентны IEnumerator из дотнета), и не умеют GetRecordNumber(x), то скорее всего там внутри делается скользящий буфер, в случае одиночного смещения превращающийся в ту самую пару значений.

Здравствуйте, alex_public, Вы писали:
_>Ну если ты так считаешь, то конечно же легко сможешь привести хотя бы один пример, в котором работа с коллекциями на базе Linq будет более быстродействующей, чем произвольный императивный код? )
Отож. Познакомьтесь с i4o.
Внезапно исполнитель автоматически опознаёт наличие индекса, и вместо O(N) получаем O(log(N)) быстродействие.
В случае "произвольного императивного кода" придётся идти и переписывать все места, где этот произвольный императивный код итерируется по нашей коллекции.

_>Это не так. Произвольные функции можно задавать как в MapReduce, так и в выражение where. Собственно единственный пример в документации к where https://docs.mongodb.com/manual/reference/operator/query/where/ как раз это демонстрирует.
Отличный пример. А есть пример, в котором все терабайты JSON не просасываются через память и медленную функцию вычисления md5 в поисках нужного?
Иначе внезапно окажется, что один инстанс SQL Server Express на моём ноуте переплюнет по производительности Монгу на кластере из 24х PowerEdge 900.
Потому, что запрос

select * from users where HASHBYTES('MD5', name) == 0x9b53e667f30cd329dca1ec9e6a83e994

В отличие от Монги использует индекс

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

_>Ну если ты так считаешь, то конечно же легко сможешь привести хотя бы один пример, в котором работа с коллекциями на базе Linq будет более быстродействующей, чем произвольный императивный код? )
Ну не надо передергивать, тут ловкий переход от for к произвольному императивному коду. =) По поводу универсальности, как я понимаю, возражений нет? Этот вопрос закрыли? )

_>Ну если бы можно было описывать любые возможные результаты, то тогда конечно. Но это явно речь не про SQL.
Да, здесь речь скорее про linq, если мы говорим про языки общего назначения. Однако и SQL в своей предметной области таки позволяет описать любые возможные результаты.

_>Мы же обсуждаем именно их, а не внешнюю красоту (тем более, что сейчас многие предпочитаю прятать этот промежуточный язык за встраиваемыми DSL'ми).
Это не внешняя красота, а удобство использования. А уж если прятать за DSL-ем, то тогда вообще не понятно причем тут язык, так как за тем же DSL-ем вполне можно спрятать и SQL, ровно с тем же эффектом.

_>Это не так. Произвольные функции можно задавать как в MapReduce, так и в выражение where. Собственно единственный пример в документации к where https://docs.mongodb.com/manual/reference/operator/query/where/ как раз это демонстрирует.
Вооот, читаем документацию внимательно: The $where provides greater flexibility, but requires that the database processes the JavaScript expression or function for each document in the collection.
Иными словами, никаких чудес нет, уныло идем по всей коллекции и применяем нашу лямбду. То есть, это полностью эквивалентно SQL запросу + прикладному коду по результатам, с точностью до синтаксиса (для сиквела, например, можно написать хранимку на .Net/C++ если что, с тем же эффектом). И это я еще исхожу из предположения, что монга таки сможет сначала ограничить выборку теми предикатами которые ей понятны и только итоговый результат пропускать через лямбду, но полной уверенности в этом нет, а то SQL еще и существенно эффективнее окажется.
Так что это точно так же отностится к классу "внешней красоты" по твоей терминологии, то бишь чисто синтаксический сахар.

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

_>Ну почему же, различных nosql систем сейчас множество, популярность их только растёт и у каждой из них обычно своя вариация на тему запросов (в том числе и частенько в виде императивного языка).
Роста популярности nosql уже давно нет, народ наигрался и переписывает все обратно на сиквел. Лучшие из nosql переквалифицировались в распределенный кэш, остальный медленно чахнут не успев взлететь.
Относительно же их языка запросов — полна печаль, в лучшем случае они цельно тянуты из какой-нибудь более-менее толковой ORM. Хуже того, к большинству nosql баз стали судорожно прикручивать аналоги SQL, так как что-то эти императивно-объектные языки хапросов не очень справляются, как только коллекцый больше чем одна и надо проекцию построить.