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

_>>Ну так переход от линейного алгоритма к логарфмическому — это и есть то самое "в разы". Только вот я так и не понял, с какой стати в твоём подходе сравнения производительности мы берём для императивного кода один алгоритм, а для Linq другой.
IB>С такой, что этот переход можно сделать не вмешиваясь в прикладной код. И в целом эта проблема решается на качественно другом уровне, позволяя сосредоточиться на реализации прикладной задачи, а не тонкостях работы конкретного алгоритма.

Какой ещё "переход"? Ты вообще осознаёшь, что изначально рассматриваешь в качестве основного сценария редкий случай, в котором изначально неправильно спроектировали систему и пришлось её переделывать?

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

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

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

А во-вторых, что ты называешь развитием языка? А то ведь появление новых функций и т.п. в sql и pl/sql происходит одновременно...

_>>Так а аналитика — это что, какая-то такая особая (может ненужная?) область что ли, развитие который мы не считаем за развитие? )))
IB>Я такого не говорил. Но в таком виде аналитика что-то не очень пошла, пока все же достают данные на клиента и применяют питон там.

Да, это так. Если данных не много (не терабайты), то удобнее анализировать в локальном Питоне с помощью pandas. А если данных много, то удобнее запускать задачи на hadoop кластере. Ну или ещё иногда бывает ситуации, когда данных не много, но всё равно используют кластер, чтобы как можно быстрее получать результат (ждать минуты, а не часы).

Кстати, не так давно видел забавную статью https://habr.com/post/347096/ на эту тему. При всей бредовости изначальной цели, в статье очень показателен набор используемых инструментов. Там есть и просто ручное исполнение независимого кода на множестве узлов (для грабинга). И работа на самом низком уровне с кластером hadoop (для парсинга html). И работа с тем же кластером через Spark (для обработки данных). И работа с тем же кластером с помощью Hive/SparkSQL (для непосредственно простенькой аналитики). И всё это не вылезая из Питончика (не считая bash скриптов для развёртывания узлов/запуска задач и то только потому, что автор похоже не в курсе IPython/Jupyter, которые позволяют и это удобно делать в Питоне).

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

_>Какой ещё "переход"? Ты вообще осознаёшь, что изначально рассматриваешь в качестве основного сценария редкий случай, в котором изначально неправильно спроектировали систему и пришлось её переделывать?

Редкий случай?

_>А во-вторых, что ты называешь развитием языка? А то ведь появление новых функций

Ты каждый раз, как новую функцию добавляешь, думаешь что развил язык?

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

IB>>С такой, что этот переход можно сделать не вмешиваясь в прикладной код. И в целом эта проблема решается на качественно другом уровне, позволяя сосредоточиться на реализации прикладной задачи, а не тонкостях работы конкретного алгоритма.

_>Какой ещё "переход"? Ты вообще осознаёшь, что изначально рассматриваешь в качестве основного сценария редкий случай, в котором изначально неправильно спроектировали систему и пришлось её переделывать?

База можно сказать всегда "неправильно" спроектирована — требования меняются постоянно, нагрузка, объемы данных. На одних объемах-нагрузке нужны одни оптимизации, на других — другие.

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

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

А по твоему сроки и деньги бесконечны ?

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

_>>Да полно их. Тот же Nemerle (из знакомой тебе платформы .net) должен справиться. Или Scala (из мира JVM). Или Rust из нативного мира.
IT>Немерле мог бы, но не сможет. Скала и Раст тоже так шоб шибко популярные, то не шибко. А больше назвать ты ничего не в состоянии.

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

_>>Пока что по существу твоё утверждение о невозможности создания механизма загрузки произвольного императивного кода в СУБД с помощью Linq оказалось ерундой. )
IT>Что-то я не припомню ни одного твоего аргумента против, кроме, конечно, я этого не понял, поэтому это не так.

Вообще то "аргументы против" должен предлагать ты, для доказательства своего глупого тезиса о невозможности подобных технологий. Я же тебе сказал что это возможно и привёл в качестве примера аналогичной технологии работу с GPU. Если же тебе хочется что-нибудь поближе к СУБД, то посмотри например на PySpark.

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

IT>Вот тебе рекурсия в Linq генераторах SQL. Причём есть идеи как сделать это в том числе и для анонимных типов.

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

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

_>>Только тогда уж это будет не в linq, а вместо linq. )))
НС>Не будет. Ты просто до сих пор не понял, что линк это не некая отельная фича, а просто набор более менее универсальных фич языка. Но дальше query comprehension ты, похоже, не пошел, и думаешь что это линк и есть.

Из фич языка, там есть ровно одна оригинальная: генерация компилятором некого AST по коду, причём с уникально убогим методом его обхода в рантайме. Всё остальное имеется в большинстве современных языков и часто в гораздо более качественном исполнение.

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

_>>А вот это уже дикий и никчемный ужас. Который может появиться только ради извращений с linq.
НС>Y combinator задолго до линка придумали, причем, емнип, в Хаскеле.

Y combinator придумали не в Хаскеле, а в лямбда-исчисление, потому как это единственный способ задать там рекурсию (в отличие от большинства языков программирования, включая Хаскель). ))) Но по сути это чисто математический приём, который абсолютно не нужен в нормальных языках программирования.

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

_>>Так и каким образом выражение "from d in data" при data являющимся int[,] делает d с типом IRelativeAccess2d<int>?
S>Это полностью определяется сигнатурой метода GroupBy, который удаётся найти для data. Либо это будет instance method (как в случае IQueryable<T>), либо extension method (как в нашем случае и в случае IEnumerable).
S>Я описал метод GroupBy так, как описал — в результате типом d стал IRelativeAccess2d<int>.
S>Для IEnumerable вторым параметром GroupBy идёт Func<TSource, TKey> keySelector, поэтому типом range variable становится TSource.

А, понял, хороший вариант. Но только тогда мгновенно возникает вопрос: а зачем при такой реализации нам вообще упоминания о linq? Просто берём этот http://rsdn.org/forum/flame.comp/7154435.1

Автор: alex_public
Дата: 26.05.18

твой код, переименовываем GroupBy во что-нибудь типа transform и используем везде в виде "res=transform(data, d=>d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]);". Где тут вообще хоть что-то полезное от linq? )))

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

_>>А программист, создающий среду исполнения, ещё меньше знает о конкретной ситуации.
S>Зато он может написать алгоритм, который будет использовать знания о конкретной ситуации для выбора оптимальной стратегии исполнения.

Который вряд ли сможет эффективно подойти под все все возможные варианты использования. Скорее будет хорошо только на каком-то самом популярном сценарии.

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

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

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

_>А во-вторых, что ты называешь развитием языка? А то ведь появление новых функций и т.п. в sql и pl/sql происходит одновременно...
Развитием языка я называю значительные эволюционные изменения. Например в тот же шарп практически с каждой версией добавляют Big Thing, типа того же linq, pattern matching, и т. д. А просто добавление новых функций — это не развитие.

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

_>Склеить строки и потом парсить их? Очаровательная идея...
Чисто for fun, но задачу решает )

_>Это же не будет работать. Смотри, у тебя в итоговой таблице должна быть строка "5 | петя". Т.е. строка, для которой в твоих обозначениях t1.id=5, а t2.count=3.
Будет, чтобы была сквозная нумерация надо лишь добавить столбец с id:

SELECT ROW_NUMBER() OVER(ORDER BY t2.name) id, t2.name FROM number t1 JOIN table t2 ON t1.id BETWEEN 1 AND t2.count

_>Да, у них сильная специфика, с этим никто не спорит. Речь как раз и была о том, что не вся специфика хорошо выражается через SQL.
Конечно не вся. Например, не структурированные данные, как в поиске — не выражаются. Но РСУБД, как раз про структурированные данные.

_>Язык вышел на самом деле вполне удачный. Для его изначального предназначения. А то, что его начали в дальнейшем использовать не по назначению (как API для СУБД) — это уже другой вопрос.
Изначальных предназначений у него было два — работа с РСУБД для бухгалтерш. С бухгалтершами получилось, для РСУБД — не очень, но лучше пока не придумали.

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

_>Это не ради рекурсии, а как способ задания произвольных выражений в большинстве языков (в них же linq нет).
Это в любом случае из пушки по комарам. Но без linq да, приходится так..

_>Нюанс только в том, что при такой реализации никаких проблем, типа задания CTE при генерации SQL по встроенному DSL, нет.
Так и в linq таких проблем нет.

_>Эм, так эта ситуация с лямбдами стандартная для большинства статических языков.
Именно.

_> И прямо в твоей же ссылке показано, что эта "проблема" тривиально решается с помощью делегатов (или например std::function в C++ и т.д.) — никаких вопросов с рекурсивными лямбдами в самом C# нет.
Ну как, строго говоря нет, но не очень удобно обходить.

_>Но в любом случае даже в языке с обычными лямбдами никаких проблем с рекурсией нет.
Это смотря что считать проблемами.

_>А вот это уже дикий и никчемный ужас. Который может появиться только ради извращений с linq.
дикий и никчемный ужас — это ваш изначальный вариант =)

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

_>Где тут вообще хоть что-то полезное от linq? )))
Можете воспринимать linq, как общепринятый контракт, между разработчиками библиотек и разработчиками прикладного кода.

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

_>Конечно. Только бизнесу становятся постепенно (с увеличением объёмов данных) нужны именно такие сценарии.
Не "именно такие", а "и такие тоже". И чтобы с такими сценариями было удобнее работать, к ним приделывают SQL

_> Но только при условии, что мы не обрезаем доступ на нижний уровень (собственно hadoop api в данном случае).
А что дает hadoop api, чего не может дать SQL?

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

_>Из фич языка, там есть ровно одна оригинальная: генерация компилятором некого AST по коду

Во-первых она не оригинальная, во-вторых какая рапзница, оригинальная или нет?

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

Однако ничего похожего на линк больше нигде не было. Потому что дело не в фичах самих по себе, а в том чтобы решалась конкретная задача.

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

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

Что как бы намекает на нужность.

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

_>А, понял, хороший вариант. Но только тогда мгновенно возникает вопрос: а зачем при такой реализации нам вообще упоминания о linq? Просто берём этот http://rsdn.org/forum/flame.comp/7154435.1

Автор: alex_public
Дата: 26.05.18

твой код, переименовываем GroupBy во что-нибудь типа transform и используем везде в виде "res=transform(data, d=>d[-1, 0] + d[1, 0] + d[0, -1] + d[0, 1]);". Где тут вообще хоть что-то полезное от linq? )))

Интересно, сколько лет тебе еще понадобиться, чтобы понять что linq это не некая вещь в себе, а просто набор относительно универсальных фич?

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

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

IT>>Вот тебе рекурсия в Linq генераторах SQL. Причём есть идеи как сделать это в том числе и для анонимных типов.

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

Что значит экспериментальная? А ну вперед использовать! Только вот чувство что тебе этого и не надо. Надо быстро за пару тактов склеить строки, а оптимизацией я как-то на досуге займусь.
Сэкономил на одном — просрал в 10 раз больше на другом. Так мне видится твой подход к работе с базами.
Linq это чудо появившееся в мире языков. Желаю твоему закостеневшему мозгу прийти к этому утверждению побыстрее.

И то что эта фича появилась только сейчас, заслуга кстати таких как ты — языками молоть гаразд, а контрибютнуть что-то полезное религия не позволяет. Мне потребовалось полтора года, чтобы только научиться тому с какой стороны подойти к реализации подобного функционала, хотя я и считаю себя очень подкованным в C#

То что linq2db не так популярен как EF или другое Г, та же заслуга тупоголовых евангелистов, которые в упор не понимают как надо работать с базой эффективно, а не как тебе жутко удобно. Да и пойди найди джуна который linq запросы клепает без StackOwerflow и к тому же хорошо разбирается в SQL. EF для них магия: базу создает, записи записывает подчиненные таблицы вытягивает. Только вот что это сразу не эффективно и им и невдомек что через год они это все перепишут на голый SQL. И будет это не проект, а борьба с проседанием производительности почти всюду. Утрирую конечно, но огромный процент больших проектов приходит к этой точке. Дальше берется Dapper и ручиками пишутся запросы — чур только не linq, на EF обожглись.

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

D>То что linq2db не так популярен как EF или другое Г, та же заслуга тупоголовых евангелистов, которые в упор не понимают как надо работать с базой эффективно, а не как тебе жутко удобно. Да и пойди найди джуна который linq запросы клепает без StackOwerflow и к тому же хорошо разбирается в SQL. EF для них магия: базу создает, записи записывает подчиненные таблицы вытягивает. Только вот что это сразу не эффективно и им и невдомек что через год они это все перепишут на голый SQL. И будет это не проект, а борьба с проседанием производительности почти всюду. Утрирую конечно, но огромный процент больших проектов приходит к этой точке. Дальше берется Dapper и ручиками пишутся запросы — чур только не linq, на EF обожглись.

А как сейчас дела с EF core?

Здравствуйте, vdimas, Вы писали:
V>Дык, ты же спорил против отдельных таблиц для движений.
V>Я приводил аргументы насчёт раздельно настраиваемых прав доступа в качестве дополнительных для схемы с отдельными таблицами движений.
Нет. Изначально я спорил насчёт того, что таблица "движений" является самой высоконагруженной. Вы, коллега, решили сместить тему обсуждения, чтобы избежать вопросов построения планов запросов по как раз нагруженным таблицам orderDetail и Orders, на специальную отдельную таблицу движений, которая дублирует OrderDetails.
При этом эта таблица, естественно, является слабонагруженной — основной вид запросов в неё это insert, и там, действительно, все интересные планы можно один раз прописать заранее.
А вся краткосрочная аналитика делается по orderDetail и Orders, ровно как в той самой схеме Northwind, которую вы пытались критиковать.

Так вот, возвращаясь к вопросу о "полезности" этой отдельной таблицы движений — я пытаюсь вам объяснить, что и без неё вопросы целостности решаются при помощи хранимых процедур.
У пользователя нет прав на модификации orderDetail, Orders, и StoredProducts. Единственный способ изменить остатки — выполнить SubmitForDelivery или ProcessReturns для какого-то ордера.
Если что-то продолжает оставаться непонятным — спрашивайте, я поясню.