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

_>>Эм, я так понимаю, ты тут подразумеваешь, что мы ручками делаем подобные запросы на все сервера и потом так же ручками их объединяем?
S>Нет, я подразумеваю, что взрослые RDBMS с Enterprise-лицензией сами раскидывают такие запросы по linked-серверам и собирают результаты автоматически.
_>>Да, и деление таблички у нас конечно же тоже руками, а не автоматическое, так? )
S>Нет, вполне себе автоматическое, по partition key.

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

_>>Так "на лету" — это внутри запроса или же админом в консоли СУБД? )))
S>Нет никакой разницы между "консолью СУБД" и "исполнением запроса".
S>Можно взять, скажем, link2db, и обучить его при встрече неожиданной aggregate-функции выполнять сериализацию её в отдельную сборку при помощи Mono.Cecil, засовывать эту сборку в сервер через create assembly from <assemblyBytes> и регистрировать агрегат при помощи create aggregate.
S>Всё это занимает меньше времени, чем прочитать этот абзац вслух, и даже меньше, чем потребуется на исполнение запроса, даже в первый раз. А последующие исполнения будут полагаться на наличие уже зарегистрированного агрегата.

Но опять же это всё не будет иметь никакого отношения к SQL.

Кстати, помнится ты в этой теме изначально был вовсе не сторонником SQL, а как раз наоборот. И ваш спор с vdimas был только по поводу разного идения претензий к SQL и соответственно того, где искать замену. А в последних сообщения ты всё упорно пытаешься защитить SQL, причём в большинстве случаев с помощью решений, вообще не имеющих к нему никакого отношения. Забавно. )))

_>>Ну например тут https://docs.mongodb.com/manual/reference/operator/aggregation/redact/#pipe._S_redact есть примеры с переменными (правда системными, а не пользовательскими, но не суть).
S>Простите, это булшит. В данном примере используются просто как именованные константы, чтобы объяснить движку, что дальше делать. Цитирую:
S>

S>The argument can be any valid expression as long as it resolves to $$DESCEND, $$PRUNE, or $$KEEP system variables. For more information on expressions, see Expressions.

S>Выделение — моё.
S>Если это тонкое место не вполне понятно, то вот пример кода:
S>

S>var userAccess = [ "STLW", "G" ];
S>db.forecasts.aggregate(
S>   [
S>     { $match: { year: 2014 } },
S>     { $redact: {
S>        $cond: {
S>           if: { $gt: [ { $size: { $setIntersection: [ "$tags", userAccess ] } }, 0 ] },
S>           then: "$$DESCEND",
S>           else: "$$PRUNE"
S>         }
S>       }
S>     }
S>   ]
S>);
S>

S>В мире типизированных языков это было бы просто enum-ом, и redact() обязан был бы вернуть что-то из Traverse.Descend, Traverse.Keep. Traverse.Prune.

А причём тут типизированные языки то? ) Или ты может SQL считаешь типизированным? )))

S>Попробуйте ещё раз. Предупреждаю: это сложнее, чем кажется. Скорее всего, первая попытка написать агрегацию с использованием глобальной переменной будет некорректной.

Это была не попытка написать агрегацию, а демонстрация работы с "глобальной" переменной из документации Монги. Первая попавшаяся, что я нашёл. )))

Да, и агрегацию с использованием глобальной переменной я писал огромное число раз и всегда без ошибок, но это всегда было в контексте того самого цикла for в императивном коде на языках типа C++. В СУБД (не важно реляционной или нет) такого писать не приходилось, но не вижу принципиальной разницы при наличие в ней полноценного императивного языка (не важно что это, pgsql, js или что-то ещё).

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

V>Но с т.з. типа T+1 — это вполне себе валидное значение.
V>Дальше продолжать?

Оно валидное, просто несравнимое. По соседству Sinclair уже отписался о варианте с unknown.

V>Можно оределить и оператор < для области опеделения T+1, если хочется.

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

S>>Они равны или не равны? Во всех этих случаях ответ false. Поэтому нельзя сравнить значение поля с null — это всегда false, даже не имеет смысла сравнивать.

V>Имеет, имеет.
V>К тому же, тривиально реализуемо.

Смотрите, вы сравниваете любое значение с unknown, результат всегда будет unknown — смысл в таком сравнении? Можно просто записать if (false) { do_something() } — эффект будет точно тот же.

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

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

V>Ну да, почти все скриптовые языки всегда "отлично справляются".
V>Но большие простыни кода на них писать не рекомендуется.

Но пишут и всё работает.

V>Возвращались бы типизированные записи, т.е. байты, которые заранее известно как реинтерпретировать, т.е. без динамического маппинга из некоего Recordset с проверкой типа каждого значения каждого поля из каждой строки, верно?

Не, я имел в виду скорее сериализацию в xml или бинарное представление. Простая ситуация — есть запрос который запрашивает только часть полей таблицы — как тут прикрутить типизированные записи? Или возвращать запись целиком, даже если понадобилось только одно поле из неё? Неэффективно нифига, как бы.

(*) Понимаю что рискую нарваться на обсуждение строгой, не строгой и немного-строгой,-но-не-очень типизации. Не надо.

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

_>>Стандарт на язык SQL оказывается уже воображаемый? )))
S>Ах, вы хотите перевести разговор на стандарт? Это тупиковая ветка дискуссии: для Монго никакого стандарта вообще не существует, так что этот забег она проиграет ещё до начала.

А причём тут вообще Монго то? ))) И что у нас за забег такой появился — снова воюем с оппонентами в своём воображение? )

_>>Ещё раз: хранимые процедуры — это не SQL. Это процедурный (императивный) язык, в то время как SQL является полностью декларативным языком.
S>Стесняюсь спросить: с чего вы это взяли?
S>Если уж вы хотите поговорить о стандартном SQL, то шокирующим откровением для вас станет часть четвёртая нынешнего ISO стандарта. И вообще, https://en.wikipedia.org/wiki/SQL/PSM:
S>

S>Initially published in 1996 as an extension of SQL-92 (ISO/IEC 9075-4:1996, a version sometimes called PSM-96 or even SQL-92/PSM[2]), SQL/PSM was later incorporated into the multi-part SQL:1999 standard, and has been part 4 of that standard since then

S>То есть хранимые процедуры, внезапно, являются частью стандарта SQL уже больше 20 лет.

А что же ты самое начало не процитировал? )))

SQL/PSM (SQL/Persistent Stored Modules) is an ISO standard mainly defining an extension of SQL with a procedural language for use in stored procedures.

_>>Я что-то не понял, это вот ты сейчас реально пытаешься снова проводить сравнение между MongoDB запросом без индекса и SQL запросом с индексом? Ты серьёзно считаешь, что настолько убогая демагогия может пройти? )))
S>При чём тут демагогия? Show me the code. Монга свой код написала. SQL свой код написал. SQL не виноват, что монга именно этот код не может эффективно исполнить. А SQL может эффективно исполнить именно этот код.
S>Не переписанный умным программистом, не оптимизированный под специфическую структуру данных, а прямо вот такой вот код, который написан 1-в-1 с технического задания: "сравнить MD5-код от имени пользователя с переданным из приложения значением".

Какое у тебя интересное видение примера из документации, демонстрирующего передачу произвольной функции... )))

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

_>>Ну так а программист с for просто потратит чуть больше времени на добавление индекса и опять же получит большее быстродействие.
S>А потом статистика данных изменится, и программисту с for опять потребуется больше времени на добавление индекса.

И? )

_>>Это всё конечно правильно, для многих усреднённых случаев. Однако это не отменяет того факта, что данная логика перестаёт работать в двух случаях:
_>>- в ряде не тривиальных задач, когда на sql/linq просто проблематично записать требуемое
S>Пока что мы таких задач не обнаружили. В обсуждённых примерах "проблематично" сводится к "я не владею linq/sql, поэтому мне проблематично написать код на них".

Угу, особенно на задачах связанных с графами. Кстати, появление всяческих xml/json (как они у нас там укладываются в реляционную алгебру?) инструментов в современных РСУБД — это тоже очень забавный знак.

_>>- когда требуется максимально возможная производительность
S>Это да. Но "максимально возможная производительность" — это эдакая странная штука. Бескомпромиссное её достижение на "произвольном императивном коде" требует бесконечного времени в практически интересных случаях.
S>Во многих случаях мы даже не знаем, чему она равна. Если не верите — перечитайте Кнута:III. Банальнейшая вещь — сортировка коллекции длины L набором из N параллельно работающих компараторов. Никто не знает вид формулы для "минимального количества стадий" от L и N, и за пределами очень-очень маленьких L и N нам точно неизвестно не только, как построить оптимальную сеть компараторов, но и даже критерий, который нам скажет "эта конфигурация — точно оптимальная".
S>А как только мы готовы чем-то пожертвовать (например, согласиться на 99% от теоретически возможной производительности) чтобы получить реалистичные сроки проекта, то тут же на передний план выбегают декларативные конструкции и прочая высокоуровневая ерунда. Особенно с учётом того, что в большинстве практически интересных проектов в списке приоритетов корректность стоит выше быстродействия — никого не интересует супералгоритм перевода денег, который в 1% случаев закидывает не ту сумму или не на тот счёт, или просто расход с приходом иногда не совпадают.

Видимо во всяких там Яндексах и Гуглах не читали Кнута. )))

_>>Как раз наоборот. Все эти noSQL СУБД являются более низкоуровневыми, так что выжать из них максимальную производительность способен только профессионал, хорошо представляющий себе алгоритмы. В то время как SQL СУБД позволяют кому попало делать приемлемо работающие запросы, при соблюдение минимального набора правил.
S>Ух ты! То есть опять наши победили?

Так я об этом ещё несколько лет назад писал. Что noSQL — это инструмент не для всех. Однако всяческих высоконагруженных сервисов и бигдата в мире становится с каждым годом больше и больше...

Кстати, так "наши" — это для тебя кто? РСУБД или всё же SQL? ))) Т.е. понятно, что в данный момент на практике разницы нет. Но говорить в теории и с учётом озвученных тобой претензий к SQL...

_>>Ха, помнится ещё лет 5 назад прямо на этом форуме было подобное сравнение. И тогда mongo обошла sql server на каких-то рядовых (а не каких-то специальных или распределённых) запроса. Помню ещё тут были шокированные вопли типа "ну это нечестно, она же в памяти всё держит" и т.п. )))
S>Естественно, если решать не ту же самую задачу. Это как если бы я попросил вас разложить на множители 4096битное число, а вы мне так: "вот — 2, 2, 3! Ну и что, что получается 12 — я же справился быстрее!"
S>Как только мы начинаем требовать банальный ACID, да хотя бы букву D из него, все эти супер-пупер-nosql решения, а также myisam из недомускула внезапно начинают тупить глазки и говорить "ну так не честно! Быстро мы умеем делать только всякую фигню, а если вам нужны гарантии, то вы можете руками навелосипедить ACID поверх нас, и он возможно даже будет работать, и не всегда медленнее изкоробочного SQL Server Express".

Эм, а что не так с ACID у Монги работающей на одной машине? )

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

V>>Но с т.з. типа T+1 — это вполне себе валидное значение.
V>>Дальше продолжать?
S>Оно валидное, просто несравнимое.

Сравнимое на мн-ве T+1.
И да, просьба перестать уже лозунгами разговаривать, сегодня прям эпидемия.
Если на твой взгляд не сравнимо, то надо указывать — потому-то и потому-то.
Пока я ни одной причины не видел, а на слово не верю.


S>По соседству Sinclair уже отписался о варианте с unknown.

Неудачная аналогия.
Unknown — это как Object в Java и .Net.
Т.е. просто самый базовый объект.


V>>Можно оределить и оператор < для области опеделения T+1, если хочется.
S>Можно определить оператор сравнения массива и числа, только это не будет иметь смысла.

Опять неудачная аналогия.
Область определения T входит в область определения T+1 целиком, поэтому — просьба указывать КОНКРЕТНУЮ причину якобы невозможности сравнения в следующий раз, ОК?


V>>Имеет, имеет.
V>>К тому же, тривиально реализуемо.
S>Смотрите, вы сравниваете любое значение с unknown, результат всегда будет unknown

Я уже выше пояснил. Любой дотнетный объект на вопрос is Object ответит true, если он не null.


S>смысл в таком сравнении? Можно просто записать if (false) { do_something() } — эффект будет точно тот же.

Можно было подобрать еще более неудачную аналогию и было бы еще смешнее.


V>>Нет в SQL никакой реляционной алгебры. Есть бестиповое реляционное исчисление в исходнике.
V>>Бестиповое — потому что сам язык имеет скриптовую природу, т.е. типизация тут сугубо динамическая.
S>Так типизация динамическая

Да.


S>или язык бестиповой?

Статически бестиповый.


S>Все столбцы имеют строго определённый тип, на любом этапе представления имеют строго определённую последовательность столбцов — где тут отсутствие типов?

В языке.


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

Не пишут и не работает.
Не зря появился Dart и TS.
А под ноду любую более-менее удачную функциональность быстрее переводят в нейтив.


S>Простая ситуация — есть запрос который запрашивает только часть полей таблицы — как тут прикрутить типизированные записи?

В этом обсуждении ответы на такого рода вопросы давались более одного раза.
Лень искать сейчас и заходить на новые круги.
Если действительно любопытно — велкам пройтись по обсуждению.


S>Или возвращать запись целиком, даже если понадобилось только одно поле из неё? Неэффективно нифига, как бы.

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


S>(*) Понимаю что рискую нарваться на обсуждение строгой, не строгой и немного-строгой,-но-не-очень типизации. Не надо.

Тут нечего обсуждать.
Хранимые данные в реляционных БД строго-типизированы.
Схема данных эквивалентна некоей библиотеке типов.
Осталось протащить эти типы в некий язык.

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

_>>Мог бы инлайнить бесстековые сопрограммы? Что-то сомневаюсь...
S>Никаких бесстековых сопрограмм не существует. MSIL — это стековый язык.

Это ты типа серьёзно хочешь сказать, что не в курсе таких терминов как stackful и stackless coroutines? )))

_>>Эмм, мы точно об одном и том же говорим? Ты считаешь, что работа с графами (дерево — это частный случай) может быть удобно реализована в рамках Linq? )))
S>Конечно же может. Как раз с такими вещами у Linq всё хорошо.
S>Но если есть какое-то недоверие к таким утверждениям, ничто не мешает написать пример задачи с графами, которая удобно реализуется в рамках "произвольного императивного кода", и посмотреть на то, как она ложится на linq.
S>А то может быть, мы неверно понимаем, что такое "работа с графами".

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

_>>Разница в том, может ли этот императивный код генерироваться нашим клиентским кодом на ходу или же должен изначально загружаться админом руками.
S>В современных СУБД этот код может генерироваться нашим клиентским кодом на лету.

Может в теории или есть практические продуманные решения?

_>>Ты только не путай расширения стандарта SQL (декларативного языка) в конкретной СУБД (ну например какие-нибудь конструкции типа connect by) и встроенный в большинство СУБД отдельный процедурный язык (у каждой свой).
S>вместо connect by в стандарте ANSI/ISO есть CTE.

Само собой. Точнее CTE — это не замена connect by, а через CTE (это всего лишь одно из применений) в стандарте SQL записываются рекурсивные запросы. Так вот connect by — не входит в стандарт SQL, а является его расширением в одной конкретной СУБД. Но при этом расширением полностью укладывающимся в классическую декларативную природу SQL. Таких расширений не мало в каждой из ведущих СУБД, особенно в области всяческих функций. Но это всё укладывается в общую схему и может даже когда-нибудь войти в стандарт. А вот всяческие pl/sql и т.п. — это абсолютно другая сущность, имеющая императивную природу. Это не расширение SQL, а изначально вообще другой язык. К сожалению авторам ведущих СУБД не удалось когда-то договориться о стандарте на него, поэтому в каждой СУБД он свой.

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

V>>РА и РИ (в сотый раз повторю) являются строго-типизированными.
V>>optional<T> — вполне себе подлежит сравнению.
S>Можно подробнее об этом? Если мы сравниваем 5 и ничего — что из них больше? Меньше? Они равны или не равны? Во всех этих случаях ответ false. Поэтому нельзя сравнить значение поля с null — это всегда false, даже не имеет смысла сравнивать.

При сравнение optional<T> абсолютно логично получить в итоге optional<bool>. Это позволяет не проводить дополнительные проверки каждого входного параметра (или столбца, в терминологии sql) на null, а провести всего одну итоговую проверку в самом конце сложных вычислений. Собственно для этого данная монада и была придумана.

Да, и кстати насколько я помню SQL приблизительно так и работает, только вот в нём реализовано автоматическое преобразование от итоговой optional<bool> к bool в конструкции where. Ну понятно, что это следствие того, что изначально SQL разрабатывался не для профессионалов, а для всяких далёких от IT людей.

S>Другое дело, что для ORM оно не нужно в большинстве случаев — в цепочке ORM->SQL->план запроса и результат->реляционное_представление->объетное_представление средние звенья очень хотелось бы исключить более низкоуровневым языком. Если, например, смотреть на запрос, который для одной записи возвращает две связи *-to-many, то всё выглядит очень плохо: нужно либо несколько запросов делать, либо строить разреженную таблицу результатами, что никак не способствует производительности. Если бы по низкоуровневому запросу вместо реляционной таблицы с результатом возвращались бы просто сериализованные объекты — было бы проще и быстрее.

Согласен.

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

V>И да, просьба перестать уже лозунгами разговаривать, сегодня прям эпидемия.

Так может в вас дело? Для фанатиков любые доводы звучат как лозунги.

V>Если на твой взгляд не сравнимо, то надо указывать — потому-то и потому-то.
V>Пока я ни одной причины не видел, а на слово не верю.

Какой результат сравнения (5)<(?) ? Вы сравниваете (5) и (unknown) — что вы получаете в результате?

V>Неудачная аналогия.
V>Unknown — это как Object в Java и .Net.
V>Т.е. просто самый базовый объект.

А NaN это базовое число в double?

V>Опять неудачная аналогия.
V>Область определения T входит в область определения T+1 целиком, поэтому — просьба указывать КОНКРЕТНУЮ причину якобы невозможности сравнения в следующий раз, ОК?

Я указывал. С примерами. От которых вы небрежно отмахнулись не приводя никаких аргументов.

S>>Смотрите, вы сравниваете любое значение с unknown, результат всегда будет unknown

V>Я уже выше пояснил. Любой дотнетный объект на вопрос is Object ответит true, если он не null.

И? Как "любой дотнетный объект" относится к операции сравнения скаляров?

V>Можно было подобрать еще более неудачную аналогию и было бы еще смешнее.

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

V>>>Нет в SQL никакой реляционной алгебры. Есть бестиповое реляционное исчисление в исходнике.
V>>>Бестиповое — потому что сам язык имеет скриптовую природу, т.е. типизация тут сугубо динамическая.
S>>Так типизация динамическая

V>Да.
V>Статически бестиповый.
V>В языке.

Проигнорирую.

V>Не пишут и не работает.
V>Не зря появился Dart и TS.
V>А под ноду любую более-менее удачную функциональность быстрее переводят в нейтив.

Говорят в C++ ввели шаблоны чтобы упростить написание сходного кода. Это не имеет отношения к обсуждению, ровно как и Dart с TS'ом, но почему бы не написать.

V>В этом обсуждении ответы на такого рода вопросы давались более одного раза.
V>Лень искать сейчас и заходить на новые круги.
V>Если действительно любопытно — велкам пройтись по обсуждению.

S>>Или возвращать запись целиком, даже если понадобилось только одно поле из неё? Неэффективно нифига, как бы.

V>Насчёт проекций тоже проходились.
V>В реляционной алгебре проекции тоже строго типизированные, ес-но.

Не хотите не надо. Если вам лень скопировать потенциально несуществующий ответ, то мне лень его искать.

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

V>>>РА и РИ (в сотый раз повторю) являются строго-типизированными.
V>>>optional<T> — вполне себе подлежит сравнению.
S>>Можно подробнее об этом? Если мы сравниваем 5 и ничего — что из них больше? Меньше? Они равны или не равны? Во всех этих случаях ответ false. Поэтому нельзя сравнить значение поля с null — это всегда false, даже не имеет смысла сравнивать.

_>При сравнение optional<T> абсолютно логично получить в итоге optional<bool>. Это позволяет не проводить дополнительные проверки каждого входного параметра (или столбца, в терминологии sql) на null, а провести всего одну итоговую проверку в самом конце сложных вычислений. Собственно для этого данная монада и была придумана.

Мне кажется это больше относится к оптимизации сравнения, а не к сравнимости null в принципе. А так да, согласен.

_>Да, и кстати насколько я помню SQL приблизительно так и работает, только вот в нём реализовано автоматическое преобразование от итоговой optional<bool> к bool в конструкции where. Ну понятно, что это следствие того, что изначально SQL разрабатывался не для профессионалов, а для всяких далёких от IT людей.

А что это меняет: вы привели Optional<bool>, в SQL используется тристейт (true, false, unknown) который ему полностью эквивалентен — при чём тут удалённость людей от IT?

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

V>>И да, просьба перестать уже лозунгами разговаривать, сегодня прям эпидемия.
S>Так может в вас дело? Для фанатиков любые доводы звучат как лозунги.

Т.е. технические доводы ты приводить отказываешься?
До свидания.

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

_>>Да, и кстати насколько я помню SQL приблизительно так и работает, только вот в нём реализовано автоматическое преобразование от итоговой optional<bool> к bool в конструкции where. Ну понятно, что это следствие того, что изначально SQL разрабатывался не для профессионалов, а для всяких далёких от IT людей.
S>А что это меняет: вы привели Optional<bool>, в SQL используется тристейт (true, false, unknown) который ему полностью эквивалентен — при чём тут удалённость людей от IT?

Я имел в виду тот факт, что по сути where делает неявный каст от optional<bool> к bool (по правилу null->false), что позволяет большинству пользователей SQL даже не быть в курсе существования этого внутреннего optional. В то время как в системах (языках) ориентированных на программистов, данный каст надо делать руками. Что с одной стороны чуть сложнее, а с другой даёт намного больше возможностей (ведь можно использовать не только такое простейшее правило) и удобства (подобный механизм в SQL всё же заставляет использовать проверку на null конкретных полей во многих случаях).

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

V>Т.е. технические доводы ты приводить отказываешься?
V>До свидания.

"Ой, всё!"? Ну ладно...

Здравствуйте, Somescout, Вы писали:
S>Под false я имел в виду что сравнение провалится. А результат в данном случае результат одинаков.
Вот нифига не одинаков. Если мы инвертируем предикат — вот прямо так: "where NOT (...)", то "обычные" строки с false начнут возвращаться, а с unknown — нет, не начнут.


S>А я вроде и не сравнивал с "обычным языком".
Это я к другому участнику

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

_>Не всё так просто. Не забывай, что бесстековая сопрограмма реализует локальные переменные под видом переменных-членов, т.е. точно как память, а не как регистры.
Это всего лишь stloc против stfld. И то и другое должно бы транслироваться в mov c таргетом в памяти.
Но что там будет на самом деле — определяется при помощи SSA и Escape Analysis

_>И что бы сделать из этого аналог императивного кода (где все переменные цикла однозначно в регистрах), надо чтобы компилятор умел понимать что это периодический вызов сопрограммы и соответственно преобразовывал его.
"Переменные цикла" "однозначно в регистрах" только потому, что компилятор видит их частоту использования и понимает, что запись в память имеет смысл отложить. А потом он видит их scope, и понимает, что отложить её можно навсегда.
То же самое мы имеем в том случае, если код енумератора заинлайнен.
Скажем, компилятору C++ совершенно наплевать, как устроен цикл — в виде обращений к скалярным переменным либо к скалярным полям локальной переменной структурного типа.

_>Ну как бы в данной подветке мы обсуждали исключительно работу с коллекциями. С СУБД и так всё понятно — там где есть Lag, имеем решение. Разве что было интересно глянуть на внутреннее устройство этой Lag (наверняка же там выбран наиболее эффективный вариант, причём не из теории).
Я посмотрел — обычный window spooling. Если выбрать переменный лаг, то можно и полную копию таблицы заспулить. Чудес не бывает.

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

S>>Под false я имел в виду что сравнение провалится. А результат в данном случае результат одинаков.
S>Вот нифига не одинаков. Если мы инвертируем предикат — вот прямо так: "where NOT (...)", то "обычные" строки с false начнут возвращаться, а с unknown — нет, не начнут.

Да, вы правы, не подумал о таком.

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

_>Кстати, помнится ты в этой теме изначально был вовсе не сторонником SQL, а как раз наоборот. И ваш спор с vdimas был только по поводу разного идения претензий к SQL и соответственно того, где искать замену. А в последних сообщения ты всё упорно пытаешься защитить SQL, причём в большинстве случаев с помощью решений, вообще не имеющих к нему никакого отношения. Забавно. )))
Я не сторонник SQL. Но вы с vdimas видите проблемы не там, где они есть.
Проблема SQL вовсе не в том, что он "не позволяет произвольный императивный код". Меня меньше всего интересуют возможности навелосипедить произвольный код, для которого невозможно проводить никакого анализа.
Меня интересуют ровно обратные возможности — повысить выразительность кода, заодно получив дополнительные возможности по оптимизации.

_>А причём тут типизированные языки то? ) Или ты может SQL считаешь типизированным? )))
Это я про то, что вы в качестве переменных скармливаете мне элементы перечисления. Полагаю, что монга использует не настоящий enum просто потому, что в JavaScript его нету.
_>Это была не попытка написать агрегацию, а демонстрация работы с "глобальной" переменной из документации Монги. Первая попавшаяся, что я нашёл. )))
Как видим — неудачная.
_>Да, и агрегацию с использованием глобальной переменной я писал огромное число раз и всегда без ошибок, но это всегда было в контексте того самого цикла for в императивном коде на языках типа C++. В СУБД (не важно реляционной или нет) такого писать не приходилось, но не вижу принципиальной разницы при наличие в ней полноценного императивного языка (не важно что это, pgsql, js или что-то ещё).
В том-то и дело, что пока вы находитесь в контексте "того самого" цикла, ваша "глобальная переменная" вполне себе локальна.
А как только вы попробуете отмасштабировать этот подход на массовый параллелизм, в том числе и за пределами одной физической машины, то внезапно окажется, что концепция "возьму-ка я значение, которое я тут прикопал на предыдущей итерации" не работает — потому что нет понятия "предыдущая итерация". А если вы настаиваете на его реализации, то ваш запрос вынужденно исполняется на 1 ядре из 1024 доступных.

Здравствуйте, alex_public, Вы писали:
_>А причём тут вообще Монго то? ))) И что у нас за забег такой появился — снова воюем с оппонентами в своём воображение? )
Ну, это же вы предложили обсудить язык "произвльно-императивных" запросов монги.
Обсуждаем: он ещё хуже, чем SQL. Менее выразительный, работает медленнее, функциональность урезана.


_>А что же ты самое начало не процитировал? )))
_>

_>SQL/PSM (SQL/Persistent Stored Modules) is an ISO standard mainly defining an extension of SQL with a procedural language for use in stored procedures.

И чему это противоречит?

_>Какое у тебя интересное видение примера из документации, демонстрирующего передачу произвольной функции... )))
Ну, технические споры, в отличие от гуманитарных, просто обязаны иногда переходить от гипербол и метафор к реальным примерам. Show me the code решает всё.

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

_>И? )
И он так и будет отставать на один шаг. В итоге у нас при честном сравнении быстродействия, "декларативное решение" будет всё время впереди.
А императивное будет бежать за ним, задыхаясь, и кричать "подождите, я вам сейчас на рояле поиграю!"

_>Угу, особенно на задачах связанных с графами. Кстати, появление всяческих xml/json (как они у нас там укладываются в реляционную алгебру?) инструментов в современных РСУБД — это тоже очень забавный знак.
Совершенно верно.
Вот ссылка на прошлый забег "связанных с графами":
http://rsdn.org/forum/philosophy/5193007.1

Автор: Ikemefula
Дата: 06.06.13

А вот результат забега, после которого беседа сама собой прекратилась:
http://rsdn.org/forum/philosophy/5199991.1

Автор: Sinclair
Дата: 13.06.13

_>Видимо во всяких там Яндексах и Гуглах не читали Кнута. )))
Читали.
_>Кстати, так "наши" — это для тебя кто? РСУБД или всё же SQL? ))) Т.е. понятно, что в данный момент на практике разницы нет. Но говорить в теории и с учётом озвученных тобой претензий к SQL...
Наши — это RDBMS.

S>>Как только мы начинаем требовать банальный ACID, да хотя бы букву D из него, все эти супер-пупер-nosql решения, а также myisam из недомускула внезапно начинают тупить глазки и говорить "ну так не честно! Быстро мы умеем делать только всякую фигню, а если вам нужны гарантии, то вы можете руками навелосипедить ACID поверх нас, и он возможно даже будет работать, и не всегда медленнее изкоробочного SQL Server Express".

_>Эм, а что не так с ACID у Монги работающей на одной машине? )
Эм, кратко — "всё".
Atomicity — если вам нужна атомарность за пределами одного документа, то будьте любезны закат солнца вручную.
Сonsistency — неа, нету. В процессе работы транзакции мы можем наблюдать произвольные состояния документов, в том числе и противоречащие друг другу.
Isolation — неа, нету. Параллельные модифицирующие транзакции наблюдают результаты друг друга, и запросто могут видеть фантомы — изменения, которые ещё будут откачены.
Durability — да, прикрутили под давлением общественности. Правда, если включить журналирование, то апдейты в монгу станут примерно такими же дорогими, как и в полноценные RDBMS.

Здравствуйте, alex_public, Вы писали:
_>Это ты типа серьёзно хочешь сказать, что не в курсе таких терминов как stackful и stackless coroutines? )))
Я хочу сказать, что никаких coroutines в MSIL нету. Ни stackful, ни stackless.

_>Хы, ну расскажи например как удобнее вычислить на linq расстояние между узлами дерева с заданными значениям и т.п.
Не вполне понимаю вопрос. Пример кода бы помог.

_>Может в теории или есть практические продуманные решения?
В теории. Но не очень далёкой от реализации. Они гораздо ближе к реализации, чем идея научить наколеночную поделку чудесам ACID в распределённой среде.

_>>>Ты только не путай расширения стандарта SQL (декларативного языка) в конкретной СУБД (ну например какие-нибудь конструкции типа connect by) и встроенный в большинство СУБД отдельный процедурный язык (у каждой свой).
S>>вместо connect by в стандарте ANSI/ISO есть CTE.

_>Само собой. Точнее CTE — это не замена connect by, а через CTE (это всего лишь одно из применений) в стандарте SQL записываются рекурсивные запросы.
Это замена в том смысле, что CTE умеет всё то, что умеет connect by. Поэтому отсутствие connect by в конкретной СУБД типа MS SQL Server не играет никакой роли.

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

_>А причём тут вообще Монго то? ))) И что у нас за забег такой появился — снова воюем с оппонентами в своём воображение? )

Позорище

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