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

IT>Я вообще, если честно, удивлён. Ладно бы если бы это были "юноша бледный со взором горящим", но вы вроде мужики уже взрослые, а как дети
IT>SQL широко известен и массово используется уже лет 30 минимум. 20 лет без него не обходится ни одно бизнес приложение в мире. Вы думаете если бы было всё так плохо и он не устраивал разработчиков, то он до сих пор был бы жив? Да за в половину меньший срок, за каких-то 10 лет, веб поменял своё лицо уже двести раз. Куча технологий появилась и умерла. А уж популярность этого дела никак не меньше, чем у SQL. Но вот почему-то SQL устраивает всех, кроме вас, а веб не пнул только ленивый.

Эм, напомни-ка пожалуйста, на что заменили при этих 200-а революциях в мире web'a убогий JS?

Ой, или же ты их тех, кто считает JavaScript венцом творения в мире языков программирования? )))

IT>Успокойтесь уже. Всё с SQL хорошо. Никакие мапредьюсы с ноусиквелами ему не грозят. Либо забьются обратно в свои изначальные ниши, точнее в щели, либо сдохнут.

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

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

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

Советую посмотреть в сторону терадаты.

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

_>Эм, напомни-ка пожалуйста, на что заменили при этих 200-а революциях в мире web'a убогий JS?

Во-первых, ещё не вечер. SQL в два раза старше JS, при этом попыток его заменить я вообще не помню. Что же касается JS, то уже есть довольно популярная альтернатива, набирающая обороты со страшной силой — TS. Большие шансы у web assemblies. Работа идёт.

Во-вторых, дело даже не в этом. Я не считаю JS убогим как язык. Я считаю убогимм концепцию нетипизированных языков в целом. SQL в этом смысле тоже не далеко ушёл. Но при всём его несовершенстве и грузе совместимости другой достольной альтернативы у него просто нет. Более того, JS действительно отягощён неподъёмным грузом несовместимости, т.к. он прибит гвоздями к миллиардам браузеров на клиентских машинах. Никто не будет использовать альтернативу, если она не будет работать в 90% случаев, пусть даже поначалу. У SQL такой проблемы нет. Любой вендор может сделать альтернативный доступ к данным, если сочтёт выши рассуждения или свои подобные чем-то стоящим. Даже ты сам можешь пойти и сделать любую шнягу в опен соурных СУБД. С вероятностью в 150% это нафиг никому не будет нужно.

_>Т.к. в данной теме обсуждалась замена SQL в первую очередь для РСУБД.

Так и я о том. В данной теме обсуждается чушь. Поэтому мне совсем не интересно перечитывать её содержимое.

Здравствуйте, alex_public, Вы писали:
_>Ты потерял нить рассуждений потому, что здесь ты ответил на мой вопрос другому участнику дискуссии, с которым обсуждалась как раз производительность (он утверждал, что for будет менее производительным чем linq на каких-то коллекциях).
Неа. Мы начали с разговоров о том, что лучше для работы с коллекциями — linq или "традиционный императивный код".
И вначале вроде бы шло рассуждение о том, что linq недостаточно выразителен, потому что вот есть такие задачи (правда, вымышленные, но речь не об этом), на которых "решение в стиле linq/sql резко увеличилось в объёме до нечитаемого".
В ответ на что был показан способ сохранить читаемость — и тут же произошло перепрыгивание в производительность.
Вот тут надо пояснить, потому что ответ Ивана не вполне понятен без знания подразумеваемого контекста.
Отступим на шаг назад и поймём, что такое "хороший" код и чем он отличается от "плохого".
Так вот: хороший код позволяет нам выражать намерения. Потому что именно намерения программиста первичны, а способ их реализации — вторичен.
Когда мы ищем в коллекции элемент с Length == 5, то это и есть наше намерение (а ещё лучше вместо 5 передать переменную или константу с самоописывающим названием).
То, что мы занимаемся перебором коллекции через for (или while, или do, или if/goto) и заводим временную переменую — это всё суета, отвлекающая нас от выражения намерения.
Если мы еще займёмся, скажем, бинарным поиском по отсортированному словарю (Length=>item), то это будет ещё хуже — намерения будут окончательно закопаны в тонну несущественного кода.
При этом, естественно, нам не хочется жертвовать производительностью. Эта жертва традиционно называется abstraction penalty, и её желательно избегать.

Тем не менее, основная мантра хорошего разработчика — "из корректного и понятного кода легко сделать высокопроизводительный, а из высокопроизводительного сделать корректный и понятный — трудно".
Поэтому приоритет всегда должен отдаваться понятности. А производительность у нас должна выигрываться как раз за счёт того, что мы внятно выразили намерение, а способ его реализации отдаём на откуп неутомимой машине, которая выбирает его наилучшим способом. Внутри компилятора С++ сидит результат огромного количества человеко-лет, потраченных на то, чтобы научиться восстанавливать намерения программиста по тупому императивному коду и реализовывать не тот код, который написан в .cpp, а тот, который лучше работает с процессором.

Теперь можно вернуться к утверждению Ивана: имея код на Linq, мы можем легко его оптимизировать, потому что намерения наши ясны, и мы можем заменять, скажем, линейный поиск на бинарный, или поиск по дереву.
И с той же лёгкостью мы можем переключаться между разными индексами, если у нас в поиске участвует композитный предикат с различной селективностью его термов.
Альтернатива на тупом императивном коде — хардкодить использование индекса. Тут, поскольку намерения замаскированы, перейти к другому решению программисту — трудно, а среде — невозможно.
Именно об этом Иван и говорил, когда писал о возможности опередить for. Я показал конкретно, на каких коллекциях linq опережает for.

_>>>Не очень понял к чему ты это написал.
S>>К тому, что $where медленно и печально перебирает всю коллекцию. Судя по их документации.
_>Так а SQL БД без индекса по данному полю будет работать как-то по другому? )
И вот здесь опять мы повторяем то же рассуждение:
1. Починить SQL БД, разогнав производительность этого кода из O(N) в O(log(N)), мы можем за пять минут работы DBA. При этом мы даже не трогаем этот SQL код — он остаётся ровно таким же, продолжая выражать намерения автора с недвусмысленной прямотой.
2. Починить вот конкретно этот $where на MongoDB потребует достаточно существенных усилий:
2.1 потребуется ввести новое поле в документы (монга не умеет строить индексы по выражениям)
2.2. потребуется выполнить массовое обновление (потому что по изменения схемы сами по себе ни на что не влияют)
2.3. потребуется построить новый индекс
2.4. потребуется переписать запрос, заменив $where на find.
Особенно здорово окажется, если такой запрос — не один.
SQL требует только п.1 и п.3.

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

_>Нет, здесь не о том речь. Я здесь говорю про разницу между таким кодом:
_>

_>for(auto c: col) f(c);
_>for(auto c: col) g(c);
_>

_>и таким кодом:
_>

_>for(auto c: col){
_>    f(c);
_>    g(c);
_>}
_>

_>Надеюсь не надо объяснять разницу?)
Надо объяснять, откуда вообще взялся код

  for(auto c: col) f(c);
  for(auto c: col) g(c);

Никакая из предложенных реализаций в стиле linq ничего подобного не порождает.

_>Переменная, используемая для агрегации по коллекции, в случае правильного императивного кода превращается в регистр процессора (соседствует с переменной, по которой идёт итерация цикла).
Ну и что? Мы же знаем, что на самом деле этих регистров процессора — много, и реальный компилятор разворачивает циклы для того, чтобы исполнитель использовал разные "eax" для соседних итераций.

Здравствуйте, alex_public, Вы писали:
S>>Просто этот "произвольный императивный код" будет адски неэффективным. То, что вы ищете, называется "курсоры". Их очень любят люди, которые мыслят категориями "ну вот мы взяли текущую запись, пощитали, потом взяли следующую" и т.п.
_>Ты что-то путаешь. Код, использующий курсоры, будет по сути работать на клиенте, используя СУБД как "удалённый" массив. А мы говорим о произвольном коде, но исполняющемся на сервере СУБД. В SQL для этого нет никаких инструментов.
Брр. Не устаю изумляться изобилию мифов про современные СУБД.
Код, использующий курсоры, выглядит примерно так:

DECLARE @name VARCHAR(50) -- database name 
DECLARE @path VARCHAR(256) -- path for backup files 
DECLARE @fileName VARCHAR(256) -- filename for backup 
DECLARE @fileDate VARCHAR(20) -- used for file name 

SET @path = 'C:\Backup\' 

SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) 

DECLARE db_cursor CURSOR FOR 
SELECT name 
FROM MASTER.dbo.sysdatabases 
WHERE name NOT IN ('master','model','msdb','tempdb') 

OPEN db_cursor  
FETCH NEXT FROM db_cursor INTO @name  

WHILE @@FETCH_STATUS = 0  
BEGIN  
      SET @fileName = @path + @name + '_' + @fileDate + '.BAK' 
      BACKUP DATABASE @name TO DISK = @fileName 

      FETCH NEXT FROM db_cursor INTO @name 
END 

CLOSE db_cursor  
DEALLOCATE db_cursor

Он целиком исполняется на сервере, безо всяких "удалённых массивов".
Что такое "произвольный код"? Чем он отличается от turing-complete T-SQL?

_>Конечно же есть всяческие императивные pl/sql и его аналоги в других РСУБД, которые как раз и реализуют данную функциональность. Но во-первых это у нас собственно уже не SQL, во-вторых решение довольно костыльное (надо в начале декларировать там что-то и т.п., а не определять императивный код прямо в запросе) и в-третьих я что-то не помню вменяемых DSL/ORM, которые могли бы эффективно задавать (генерируя процедуры и т.п.) такое в наших клиентских языках.
Опять какое-то передёргивание. Откуда взялось требование "эффективно задавать" что-то в клиентских языках? Клиентский язык является потребителем SQL.
Здесь речь идёт о том, что вот такое использование курсоров — оно вполне есть. Вот только замена этих курсоров на нормальные декларативные SQL statements обычно даёт рост производительности на порядок.

_>Ещё раз повторюсь: полноценные индексы есть и в MongoDB. И в случае таких простейших случаев, как запрос прямо по индексу, и у удобство и быстродействие скорее всего не будет существенно отличаться. А вот в более нетривиальных случаях уже надо смотреть детали — я вполне себе могу представить ситуации, где будет выигрыш как одной стороны, так и и другой, в зависимости от типа задачи.
Ох-хо. Это мне напоминает байку про то, как в семидесятые годы один из пионеров ИИ научил экспертную систему играть в "космический бой" (усложнённый аналог обычного морского боя). На чемпионате штата его программа выиграла у живых игроков с большим отрывом. На следующий год организаторы усложнили правила, надеясь обыграть ЭС. Увы — ей было наплевать на сложность правил. А вот живым игрокам — нет, поэтому их просто размазали в тонкую пыль.
После этого участие ИИ в чемпионате было запрещено.
Так и тут — чем сложнее будет задача, тем больше шансы, что рукопашная реализация на noSQL склеит ласты в гонке с SQL/RBDMS.
У SQL есть только один фатальный недостаток — его надо изучать.

_>Эм, вот уж как раз про организацию работы по распределённым серверам РСУБД лучше не заикаться — оно тупо не умеет и как раз из-за этого и появилось большинство nosql СУБД.
Большинство noSQL СУБД появились как реакция на то, что большинство "фулл-стек" программистов не были способны ни на что, кроме написания кода по доставанию объектов по ID из RDBMS (c помощью ORM естественно).
Посмотрев на это критическим взором, умные люди поняли, что вся адская мощь реляционных движков простаивает, и проще дать горе-программистам инструмент по руке. А через десять лет внезапно оказалось, что роторный экскаватор всё же котлован копает быстрее, чем Джо с лопатой. Вот только им надо учиться управлять.

Здравствуйте, alex_public, Вы писали:
_>Ну во-первых тут была речь не про MapReduce (это вообще странно тут привлекать, т.к. у этого дела нет вообще никаких аналогов в мире РСУБД)
Вообще-то — есть.

_>а про другие возможности использования императивного кода. А во-вторых какое отношение custom aggregate имеет к SQL? )
Самое прямое. Как только мы определили Custom Aggregate, мы можем его использовать в совершенно обычных, декларативных SQL Statements.

_>Если говорить про ту задачку, что мы обсуждали для коллекций, то мне не очевидно как её сделать и на SQL (т.к. там были "вложенные" коллекции, кстати как раз на MongoDB такое делать проще, т.к. там вложенные структуры — это норма).
Ну, давайте предположим, что у нас есть классический Orders(id int identity, name varchar(max)) и OrderDetails(orderID int not null foreign key references orders(id), productID int not null foreign key references products, quantity int not null). Вот и вложенная коллекция.

_>Если же говорить о самой сути проблемы, которую мы обсуждали и для решения которой в SQL есть функции lag и lead, то для анализа "между документами" в MongoDB ты можешь банально использовать "глобальную" переменную, причём сделать её например массивом по ключу и класть в неё результат условия. Ну а в случае хранения коллекции не как набора документов, а как массива внутри одного документа, то ситуация сводится к банальному JS коду работы с массивом. )))
Ок, ждём примера кода.

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

_> Собственно он и внутри любого выражения linq сидит. Только там он существенно ограничен.
Чем? Ты все время упоминаешь какие-то мифические ограничения, но пока так и не смог их сформулировать.

_>По поводу универсальности чего? Если речь про работу с коллекциями в стиле sql/linq, то очевидно же, что там есть существенные ограничения.
Какие?

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

_>Если бы SQL мог передать всё (как это может например произвольный императивный код), то конечно. А так у нас DSL ограничен этим промежуточным языком,
Нет, не ораничен. Там где SQL заканчивается, можно совершенно спокойно использовать императивный код. Что мешает то?


_>И? Никто тут про какие-то чудеса не говорил. Речь шла про недоступное для SQL. И указанное является недоступным ("хранимка на .Net/C++" — это уже не SQL).
Так и JS код в монге — это не язык запросов монги. и в этом смысле он точно так же недоступен.
Еще раз. SQL + хранимка на .Net/C++ то же самое, что запрос на языке монги + JS, с точностью до синтаксиса.

_>Т.е. ты можешь на SQL записать произвольный императивный код? )))
Легко.

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

_> Но та же MongoDB или Cassandra явно не относятся к кэшам, однако прекрасно чувствуют себя на рынке.
Да что-то не очень прекрасно..

_>Причём в последнее время можно увидеть уже и такие https://www.ibm.com/communities/analytics/riskmanagement-blog/big-data-for-banking-which-database-model-is-best-for-you/ статьи — дело дошло даже до таких матёрых консерваторов, как банки.
Статья вообще огонь, они в серьез MySQL как образец реляционных баз берут. Ну в целом верно, уровень NoSQL баз примерно такой же.

_>Ну так в SQL конечно же тоже есть много полезного — совершенно логично взять всё лучшее и из него тоже.
Все лучшее — это собственно SQL? В котором нашелся фатальный недостаток, но все еще не получается объяснить какой? )

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

_>>Эм, напомни-ка пожалуйста, на что заменили при этих 200-а революциях в мире web'a убогий JS?
IT>Во-первых, ещё не вечер. SQL в два раза старше JS, при этом попыток его заменить я вообще не помню. Что же касается JS, то уже есть довольно популярная альтернатива, набирающая обороты со страшной силой — TS. Большие шансы у web assemblies. Работа идёт.

TS — это замена JS? Хорошая шутка...

А вот WASM — это да, потенциально реальная замена. Но только тогда, когда будет реализован полноценный новый DOM API (это есть в планах, но где-то очень далеко, после SIMD, многопоточности и ещё много чего). А пока целевым применением WASM является только ускорение производительности для специфических задач типа кодеков, криптографии и т.п.

IT>Во-вторых, дело даже не в этом. Я не считаю JS убогим как язык. Я считаю убогимм концепцию нетипизированных языков в целом. SQL в этом смысле тоже не далеко ушёл. Но при всём его несовершенстве и грузе совместимости другой достольной альтернативы у него просто нет. Более того, JS действительно отягощён неподъёмным грузом несовместимости, т.к. он прибит гвоздями к миллиардам браузеров на клиентских машинах. Никто не будет использовать альтернативу, если она не будет работать в 90% случаев, пусть даже поначалу. У SQL такой проблемы нет. Любой вендор может сделать альтернативный доступ к данным, если сочтёт выши рассуждения или свои подобные чем-то стоящим. Даже ты сам можешь пойти и сделать любую шнягу в опен соурных СУБД. С вероятностью в 150% это нафиг никому не будет нужно.

Хы, вообще то уже давным давно все основные браузеры сами апдейтятся, так что при желание (если бы производители 4-ёх основных браузеров договорились о едином кандидате на замену JS) новая технология стала бы доступной у большинства клиентов мгновенно. Собственно с теми же WASM именно так и произошло.

_>>Т.к. в данной теме обсуждалась замена SQL в первую очередь для РСУБД.
IT>Так и я о том. В данной теме обсуждается чушь. Поэтому мне совсем не интересно перечитывать её содержимое.

Тогда зачем ты участвуешь в дискуссии, если для тебя это всё чушь? )))

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

_>>Ты потерял нить рассуждений потому, что здесь ты ответил на мой вопрос другому участнику дискуссии, с которым обсуждалась как раз производительность (он утверждал, что for будет менее производительным чем linq на каких-то коллекциях).
S>Неа. Мы начали с разговоров о том, что лучше для работы с коллекциями — linq или "традиционный императивный код".
S>И вначале вроде бы шло рассуждение о том, что linq недостаточно выразителен, потому что вот есть такие задачи (правда, вымышленные, но речь не об этом), на которых "решение в стиле linq/sql резко увеличилось в объёме до нечитаемого".
S>В ответ на что был показан способ сохранить читаемость — и тут же произошло перепрыгивание в производительность.
S>Вот тут надо пояснить, потому что ответ Ивана не вполне понятен без знания подразумеваемого контекста.
S>Отступим на шаг назад и поймём, что такое "хороший" код и чем он отличается от "плохого".
S>Так вот: хороший код позволяет нам выражать намерения. Потому что именно намерения программиста первичны, а способ их реализации — вторичен.
S>Когда мы ищем в коллекции элемент с Length == 5, то это и есть наше намерение (а ещё лучше вместо 5 передать переменную или константу с самоописывающим названием).
S>То, что мы занимаемся перебором коллекции через for (или while, или do, или if/goto) и заводим временную переменую — это всё суета, отвлекающая нас от выражения намерения.
S>Если мы еще займёмся, скажем, бинарным поиском по отсортированному словарю (Length=>item), то это будет ещё хуже — намерения будут окончательно закопаны в тонну несущественного кода.
S>При этом, естественно, нам не хочется жертвовать производительностью. Эта жертва традиционно называется abstraction penalty, и её желательно избегать.
S>Тем не менее, основная мантра хорошего разработчика — "из корректного и понятного кода легко сделать высокопроизводительный, а из высокопроизводительного сделать корректный и понятный — трудно".
S>Поэтому приоритет всегда должен отдаваться понятности. А производительность у нас должна выигрываться как раз за счёт того, что мы внятно выразили намерение, а способ его реализации отдаём на откуп неутомимой машине, которая выбирает его наилучшим способом. Внутри компилятора С++ сидит результат огромного количества человеко-лет, потраченных на то, чтобы научиться восстанавливать намерения программиста по тупому императивному коду и реализовывать не тот код, который написан в .cpp, а тот, который лучше работает с процессором.
S>Теперь можно вернуться к утверждению Ивана: имея код на Linq, мы можем легко его оптимизировать, потому что намерения наши ясны, и мы можем заменять, скажем, линейный поиск на бинарный, или поиск по дереву.
S>И с той же лёгкостью мы можем переключаться между разными индексами, если у нас в поиске участвует композитный предикат с различной селективностью его термов.
S>Альтернатива на тупом императивном коде — хардкодить использование индекса. Тут, поскольку намерения замаскированы, перейти к другому решению программисту — трудно, а среде — невозможно.
S>Именно об этом Иван и говорил, когда писал о возможности опередить for. Я показал конкретно, на каких коллекциях linq опережает for.

Это всё конечно верные (по большей части — мелкие поправки конечно можно внести, но это не суть в данной дискуссии) рассуждения, только вот они не имеют никакого отношения к тому тезису, несогласие с которым я тут выразил. То, что ты тут описываешь, можно в некотором роде описывать понятием "скорость рефакторинга", в то время как в обсуждаемом тезисе фигурировало совершенно другое понятие "скорость кода". И даже отдалённая косвенная связь между этими понятиями возможна только при кривой организации разработки (когда требования подгоняют под сроки, а не наоборот, как должно быть).

И не стоит втаскивать в этот конкретный вопрос (причём обсуждавшийся ещё и не с тобой) всю нашу с тобой обобщённую дискуссию, в которой действительно есть место неоднозначным суждениям и вкусовщине. А в данном конкретном вопросе IB высказал вполне однозначное и очевидно не верное утверждение. Что должно быть просто отмечено (если он конечно не пожелает упереться и попытаться доказать его, как изредка делают некие редкие неадекваты на этом форуме) и вычеркнуто из дискуссии.

_>>>>Не очень понял к чему ты это написал.
S>>>К тому, что $where медленно и печально перебирает всю коллекцию. Судя по их документации.
_>>Так а SQL БД без индекса по данному полю будет работать как-то по другому? )
S>И вот здесь опять мы повторяем то же рассуждение:
S>1. Починить SQL БД, разогнав производительность этого кода из O(N) в O(log(N)), мы можем за пять минут работы DBA. При этом мы даже не трогаем этот SQL код — он остаётся ровно таким же, продолжая выражать намерения автора с недвусмысленной прямотой.
S>2. Починить вот конкретно этот $where на MongoDB потребует достаточно существенных усилий:
S>2.1 потребуется ввести новое поле в документы (монга не умеет строить индексы по выражениям)
S>2.2. потребуется выполнить массовое обновление (потому что по изменения схемы сами по себе ни на что не влияют)
S>2.3. потребуется построить новый индекс
S>2.4. потребуется переписать запрос, заменив $where на find.
S>Особенно здорово окажется, если такой запрос — не один.
S>SQL требует только п.1 и п.3.

Хы, все твои рассуждения тут базируются на том, что у нас имеется запрос вида "where id=123" или чуть сложнее, который естественно без проблем записывается на SQL и оптимизируется индексом. Только вот совершенно непонятно, с чего это мы подобный запрос в MongoDB решили записать через функцию, а не через такой же find с индексом? Очевидно же, что если у нас применена какая-то нетривиальная кастомная функция, то на SQL это вообще ещё надо будет умудриться суметь записать, а не про какие-то там индексы думать.

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

_>>Нет, здесь не о том речь. Я здесь говорю про разницу между таким кодом:
_>>

_>>for(auto c: col) f(c);
_>>for(auto c: col) g(c);
_>>

_>>и таким кодом:
_>>

_>>for(auto c: col){
_>>    f(c);
_>>    g(c);
_>>}
_>>

_>>Надеюсь не надо объяснять разницу?)
S>Надо объяснять, откуда вообще взялся код
S>

S>  for(auto c: col) f(c);
S>  for(auto c: col) g(c);
S>

S>Никакая из предложенных реализаций в стиле linq ничего подобного не порождает.

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

_>>Переменная, используемая для агрегации по коллекции, в случае правильного императивного кода превращается в регистр процессора (соседствует с переменной, по которой идёт итерация цикла).
S>Ну и что? Мы же знаем, что на самом деле этих регистров процессора — много, и реальный компилятор разворачивает циклы для того, чтобы исполнитель использовал разные "eax" для соседних итераций.

Разница в том, что в твоём коде аналогичная переменная не будет регистром.

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

_>И не стоит втаскивать в этот конкретный вопрос (причём обсуждавшийся ещё и не с тобой) всю нашу с тобой обобщённую дискуссию, в которой действительно есть место неоднозначным суждениям и вкусовщине. А в данном конкретном вопросе IB высказал вполне однозначное и очевидно не верное утверждение. Что должно быть просто отмечено (если он конечно не пожелает упереться и попытаться доказать его, как изредка делают некие редкие неадекваты на этом форуме) и вычеркнуто из дискуссии.
Нет, Иван высказал вполне однозначное и очевидно верное утверждение.
А вот вы, коллега, передёргиваете. Иван отвечал на вопрос про for(). А вы лёгким движением руки превратили его в "произвольный императивный код".
В такой жульнической постановке вопрос не имеет смысла — просто потому, что под капотом у linq (да и вообще у чего угодно) исполняется самый обычный императивный код.
Поэтому можно посмотреть на linq код, на выхлоп компилятора, и тупо среверсить его в "императивную форму". А если попутно удастся срезать пару углов за счёт тупости обычного JIT-а, то можно и обыграть linq.
А вопрос о том, что linq код может порождать совершенно разные императивные версии кода в зависимости от мелких изменений контекста мы типа оставим за кадром, объявив его "скоростью рефакторинга".

_>Хы, все твои рассуждения тут базируются на том, что у нас имеется запрос вида "where id=123" или чуть сложнее, который естественно без проблем записывается на SQL и оптимизируется индексом.
Мои рассуждения базируются ровно на примере из документации Монги. Я не виноват, что они в своей документации приводят пример, на котором их обходит SQL сервер 10-летней давности.
_>Только вот совершенно непонятно, с чего это мы подобный запрос в MongoDB решили записать через функцию, а не через такой же find с индексом?
А по-моему совершенно понятно. "find c индексом" на монге потребует нетривиальных приседаний, и программист поленился. Примеров программистов, пишущих говнокод в SQL — миллионы. С чего это мы ожидаем, что они внезапно на Монге озаботятся производительностью и начнут продумывать индексы? Тем более, что монга беспощадна к тем, кто решил добавить индексы к большому объёму данных.
_>Очевидно же, что если у нас применена какая-то нетривиальная кастомная функция, то на SQL это вообще ещё надо будет умудриться суметь записать, а не про какие-то там индексы думать.
Я всё ещё жду монго-примера, на котором она выигрывает у SQL, а не наоборот.

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

S>Брр. Не устаю изумляться изобилию мифов про современные СУБД.
S>Код, использующий курсоры, выглядит примерно так:
S>

S>DECLARE @name VARCHAR(50) -- database name 
S>DECLARE @path VARCHAR(256) -- path for backup files 
S>DECLARE @fileName VARCHAR(256) -- filename for backup 
S>DECLARE @fileDate VARCHAR(20) -- used for file name 
S>SET @path = 'C:\Backup\' 
S>SELECT @fileDate = CONVERT(VARCHAR(20),GETDATE(),112) 
S>DECLARE db_cursor CURSOR FOR 
S>SELECT name 
S>FROM MASTER.dbo.sysdatabases 
S>WHERE name NOT IN ('master','model','msdb','tempdb') 
S>OPEN db_cursor  
S>FETCH NEXT FROM db_cursor INTO @name  
S>WHILE @@FETCH_STATUS = 0  
S>BEGIN  
S>      SET @fileName = @path + @name + '_' + @fileDate + '.BAK' 
S>      BACKUP DATABASE @name TO DISK = @fileName 
S>      FETCH NEXT FROM db_cursor INTO @name 
S>END 
S>CLOSE db_cursor  
S>DEALLOCATE db_cursor 
S>

S>Он целиком исполняется на сервере, безо всяких "удалённых массивов".
S>Что такое "произвольный код"? Чем он отличается от turing-complete T-SQL?

А какое отношение этот всё имеет к SQL? Или ты относишь к нему t-sql, pl/sql, pl/pgsql и д.р. только потому, что там тоже есть буквы SQL? )))

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

_>>Конечно же есть всяческие императивные pl/sql и его аналоги в других РСУБД, которые как раз и реализуют данную функциональность. Но во-первых это у нас собственно уже не SQL, во-вторых решение довольно костыльное (надо в начале декларировать там что-то и т.п., а не определять императивный код прямо в запросе) и в-третьих я что-то не помню вменяемых DSL/ORM, которые могли бы эффективно задавать (генерируя процедуры и т.п.) такое в наших клиентских языках.
S>Опять какое-то передёргивание. Откуда взялось требование "эффективно задавать" что-то в клиентских языках? Клиентский язык является потребителем SQL.

Ээээ что? Клиентский язык в текущей реальности занят генерацией sql (с помощью склейки строк или чего-то более автоматизированного), который служит промежуточным языком между клиентским кодом и СУБД.

_>>Ещё раз повторюсь: полноценные индексы есть и в MongoDB. И в случае таких простейших случаев, как запрос прямо по индексу, и у удобство и быстродействие скорее всего не будет существенно отличаться. А вот в более нетривиальных случаях уже надо смотреть детали — я вполне себе могу представить ситуации, где будет выигрыш как одной стороны, так и и другой, в зависимости от типа задачи.
S>Ох-хо. Это мне напоминает байку про то, как в семидесятые годы один из пионеров ИИ научил экспертную систему играть в "космический бой" (усложнённый аналог обычного морского боя). На чемпионате штата его программа выиграла у живых игроков с большим отрывом. На следующий год организаторы усложнили правила, надеясь обыграть ЭС. Увы — ей было наплевать на сложность правил. А вот живым игрокам — нет, поэтому их просто размазали в тонкую пыль.
S>После этого участие ИИ в чемпионате было запрещено.
S>Так и тут — чем сложнее будет задача, тем больше шансы, что рукопашная реализация на noSQL склеит ласты в гонке с SQL/RBDMS.
S>У SQL есть только один фатальный недостаток — его надо изучать.

Интересно, а что ты называешь сложной задачей? Наверное что-нибудь типа 10-и уровневого join'а и т.п. артефактов криворуких архитекторов? ) А как на твой взгляд задачка с простейшим фильтром по одной коллекции, но при этом отрабатывающая одновременно на десятках независимых узлов в сети — это сложная или нет? )))

_>>Эм, вот уж как раз про организацию работы по распределённым серверам РСУБД лучше не заикаться — оно тупо не умеет и как раз из-за этого и появилось большинство nosql СУБД.
S>Большинство noSQL СУБД появились как реакция на то, что большинство "фулл-стек" программистов не были способны ни на что, кроме написания кода по доставанию объектов по ID из RDBMS (c помощью ORM естественно).
S>Посмотрев на это критическим взором, умные люди поняли, что вся адская мощь реляционных движков простаивает, и проще дать горе-программистам инструмент по руке. А через десять лет внезапно оказалось, что роторный экскаватор всё же котлован копает быстрее, чем Джо с лопатой. Вот только им надо учиться управлять.

Это у тебя какое-то искажённое восприятие реальности. Большинство noSQL СУБД появились на фоне модели MapReduce, предложенной в своё время Google. Т.к. SQL очевидно не имел (и до сих пор не имеет) возможности работы с подобными моделями, то от него пришлось отказаться. По сути это был вынужденный шаг (естественно люди предпочли бы работать с уже известным инструментом, если бы это было возможно), вследствие которого каждый стал придумывать что-то своё, а всё это множество совершенно разных СУБД стали называть noSQL.

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

_>>Ну во-первых тут была речь не про MapReduce (это вообще странно тут привлекать, т.к. у этого дела нет вообще никаких аналогов в мире РСУБД)
S>Вообще-то — есть.

И какой же? )

_>>а про другие возможности использования императивного кода. А во-вторых какое отношение custom aggregate имеет к SQL? )
S>Самое прямое. Как только мы определили Custom Aggregate, мы можем его использовать в совершенно обычных, декларативных SQL Statements.

Угу, но задать его в sql запросе ты не можешь.

_>>Если говорить про ту задачку, что мы обсуждали для коллекций, то мне не очевидно как её сделать и на SQL (т.к. там были "вложенные" коллекции, кстати как раз на MongoDB такое делать проще, т.к. там вложенные структуры — это норма).
S>Ну, давайте предположим, что у нас есть классический Orders(id int identity, name varchar(max)) и OrderDetails(orderID int not null foreign key references orders(id), productID int not null foreign key references products, quantity int not null). Вот и вложенная коллекция.

и?

_>>Если же говорить о самой сути проблемы, которую мы обсуждали и для решения которой в SQL есть функции lag и lead, то для анализа "между документами" в MongoDB ты можешь банально использовать "глобальную" переменную, причём сделать её например массивом по ключу и класть в неё результат условия. Ну а в случае хранения коллекции не как набора документов, а как массива внутри одного документа, то ситуация сводится к банальному JS коду работы с массивом. )))
S>Ок, ждём примера кода.

Какого? )

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

_>TS — это замена JS? Хорошая шутка...

А в чём проблема? Если ты про то, что TS всего лишь генерирует JS, то в своё время C++ тоже всего лишь генерировал C.

_>А вот WASM — это да, потенциально реальная замена. Но только тогда, когда будет реализован полноценный новый DOM API (это есть в планах, но где-то очень далеко, после SIMD, многопоточности и ещё много чего). А пока целевым применением WASM является только ускорение производительности для специфических задач типа кодеков, криптографии и т.п.

Пока для WASM просто отсутствуют приличные средства разарбоатки. Но уже показали blazor и народ заинтересовался.

IT>>Так и я о том. В данной теме обсуждается чушь. Поэтому мне совсем не интересно перечитывать её содержимое.
_>Тогда зачем ты участвуешь в дискуссии, если для тебя это всё чушь? )))

Потому что ты меня постоянно в это втягиваешь.

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

_>> Собственно он и внутри любого выражения linq сидит. Только там он существенно ограничен.
IB>Чем? Ты все время упоминаешь какие-то мифические ограничения, но пока так и не смог их сформулировать.

Вообще то прямо в этой темке уже был конкретный пример с доступом к предыдущим элементам. Если его мало, то можно ещё накидать — например поговорить о таких коллекциях как деревья и т.п. )))

_>>Ну если в стиле секса в гамаке, то возможно. А по нормальному (читай по удобному) в sql доступно только определённое подмножество задач работы с коллекциями.
IB>Так он и сделан ровно для того, чтобы работать исключительно с коллекциями. И лучше пока ничего не придумали.

Ты видимо как-то странно прочитал мою фразу. )))

_>>Если бы SQL мог передать всё (как это может например произвольный императивный код), то конечно. А так у нас DSL ограничен этим промежуточным языком,
IB>Нет, не ораничен. Там где SQL заканчивается, можно совершенно спокойно использовать императивный код. Что мешает то?

Что ты здесь имеешь в виду? Код выполняемый на клиенте или на сервере?

_>>И? Никто тут про какие-то чудеса не говорил. Речь шла про недоступное для SQL. И указанное является недоступным ("хранимка на .Net/C++" — это уже не SQL).
IB>Так и JS код в монге — это не язык запросов монги. и в этом смысле он точно так же недоступен.
IB>Еще раз. SQL + хранимка на .Net/C++ то же самое, что запрос на языке монги + JS, с точностью до синтаксиса.

Ну так а ты этот C++ код передаёшь в СУБД внутри SQL запроса или как? )

_>>Т.е. ты можешь на SQL записать произвольный императивный код? )))
IB>Легко.

Покажешь пример? Если ты конечно же не подразумеваешь под SQL (априори декларативным языком) какой-нибудь из процедурных языков с похожими названиями (типа pl/sql), как делают изредка неграмотные специалисты.

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

_>Ну как же. Напомню, что в той нашей задачке происходила фильтрация по условию количества элементов внутренней коллекции в предыдущем элементе (который ты перевёл в текущий с помощью копирования). Т.е. при таком подходе у тебя на верхнем уровне получается не пара значений, а пара коллекций, которые ты соответственно обрабатываешь циклами.
А, я понял. Хочется наиграть на том, что мы типа итерируемся по коллекции, и сэкономить проход цикла. Ну, идея сама по себе интересная, хотя насколько драматичным будет выигрыш в производительности — вопрос открытый.
То есть понятно, что по факту linq проиграет, но не из-за семантики, а из-за того, что оптимизатор JIT-а сосёт.
А в том случае, если мы вычисляем одну и ту же f() от предыдущей и следующей коллекции, мы по-прежнему можем сэкономить на проходе цикла, сделав PairScan по результатам вычисления, а не по самой коллекции.

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

_>И какой же? )
Ну тот же самый

select MyAggregate(valueColumn) from PartitionedTable group by groupKey(....)

Ничего военного map/reduce не делает.

S>>Самое прямое. Как только мы определили Custom Aggregate, мы можем его использовать в совершенно обычных, декларативных SQL Statements.
_>Угу, но задать его в sql запросе ты не можешь.
Ну почему же не могу? Он же не сошествием священного огня в сервере заводится.
Нет никаких проблем добавить его прямо на лету, если нам вдруг понадобилось что-то такое, что нельзя было сформулировать на этапе развёртывания базы. Понадобится буквально две команды, чтобы он завёлся.
Потенциально ничего не мешает и определять этот кастом агрегат прямо на SQL, кроме нежелания писать компилятор.

_>>>Если говорить про ту задачку, что мы обсуждали для коллекций, то мне не очевидно как её сделать и на SQL (т.к. там были "вложенные" коллекции, кстати как раз на MongoDB такое делать проще, т.к. там вложенные структуры — это норма).
S>>Ну, давайте предположим, что у нас есть классический Orders(id int identity, name varchar(max)) и OrderDetails(orderID int not null foreign key references orders(id), productID int not null foreign key references products, quantity int not null). Вот и вложенная коллекция.
_>и?
Напишите тот код, который вам не очевидно, как сделать на SQL.

_>>>Если же говорить о самой сути проблемы, которую мы обсуждали и для решения которой в SQL есть функции lag и lead, то для анализа "между документами" в MongoDB ты можешь банально использовать "глобальную" переменную, причём сделать её например массивом по ключу и класть в неё результат условия. Ну а в случае хранения коллекции не как набора документов, а как массива внутри одного документа, то ситуация сводится к банальному JS коду работы с массивом. )))
S>>Ок, ждём примера кода.
_>Какого? )
Какого-то нетривиального кода на Монге, где она пользуется "глобальной" переменной, и при этом работает корректно. А я попробую запустить аналог на моём ноуте на SQL Server Express 2017

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

S>А это как раз, например, мы. Приходим и чиним. Да, долго. По паре дней на одну такую индусохранимку. По которой нет ни тестов, ни документации, ни примеров использования. Зато результат есть.

(поскольку здесь КСВ, то я не думаю, что это будет совсем уж оффтопиком)

Вам надо рекламный ролик сделать. В духе:
https://www.youtube.com/watch?v=jqyHuSlg7qY