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

I>>А вот это ты мог бы пояснить примером? Я cte юзал один раз и даже непомню для чего именно.
IB>Не CTE грязное, а попытка записать рекурентную лямбду в C# грязная. С CTE все норм.

Это имеется ввиду тот самый Y-комбинатор и прочее паскудство, так ? В своё время я такого натаскал в либу, потом плакал горкими слезами и выдирал обратно. Туда-обратно ушло около полугода и то, до конца не вычистил. Код получился как с регэкспами — каждый раз лезешь и изучаешь заново.

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

I>Это имеется ввиду тот самый Y-комбинатор и прочее паскудство, так ?
Именно.

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


Gt_>>>да уже все показывал и детально разжевывал чем функция на дотнете отличается
Gt_>>>http://www.rsdn.org/forum/flame.comp/7153190.1
В том топике, вы бесславно слились, так и не пояснив, к чему это все было. И вот опять..

Gt_>там вставка итеративных жава команд в декларативную конструкцию спаркового датафрейма.
То есть, декларативная конструкция отдельно, интерактивная обработка результата декларативного вызова — отдельно. Иными словами, пример опять не про то.

Gt_> то самое о чем толдычит alex_public, что не надо нас ограничивать куцым декларативным sql из нескольких команд.
О чем вы талдычите — понятно, не понятно в чем вас сиквел ограничивает.

Gt_> оказалось "стандартный" набор алгоритмов spark ml достаточно куций, но поскольку это не mssql я не ограничен парой sql команд.
В MSSQL тоже не ограничены, но опустим это, речь то не про mssql...

Gt_> а элегантно это выглядит потому что я не ограничен декларативными конструкциями и могу итеративный код использовать наравне с декларативными конструкциями датафреймов.
Вот опять. Как мы выяснили, спарк отлично работает с sql, зачем что-то кроме SQL в декларативной части? То что можно выполнить императивный код по результатам запроса уже восемь раз обсудили, зачем интерактив при выполнении самого запроса?

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

V>>Или ты опять предлагаешь при добавлении нового типа документа скакать по всей базе в поисках зависимостей? ))
S>Я вообще ничего про "скакать" не предлагаю. Это вы пытаетесь от неудобной для вас темы планов запросов перейти к вопросам дизайна базы.
V>>Да я уже понял, что ты хотел на досуге поиграть с показанной схемой... хотел, хотел... но обломался.
S> Я поиграл, но понял, что это был ложный манёвр — внести в обсуждение лишнюю таблицу.

Не "лишнюю", а "единственную".
Я задавал прямой вопрос — "сколько таких таблиц в базе?"
По твоей версии их должно быть сотни, т.е. мощность мн-ва всех планов ты оценил на пару порядков больше, чем я.
Это объясняет некоторые твои взгляды по состоянию на начало обсуждения.


S>В реальности всё упирается в orders и orderDetails

Бог с тобой.
В реальности видов orders многие десятки, иногда больше сотни.
Каждый из них живёт в своей уникальной таблице.
Т.е. умножай на сотню сходу.


S>и мы возвращаемся к исходной точке — в классических примерах там 8 индексов

В таблице movements 3 индекса в классике (один составной).
В таблице documents — зависит от.
Ну пусть даже 5-6.
Эти таблицы единственные в своём роде.
Практически все остальные данные имеют справочный характер (кроме "исходников" документов).
По "исходникам" никакая аналитика не гоняется.

Кароч, всё это страшно далеко от "сотен таблиц с 15-ю индексами в каждой" (С)


S>и ровно потому, что по этой таблице строятся аналитические отчёты.

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


S>Когда вы начнёте делать такие же отчёты по таблице движений, то придётся добавить те же индексы, и вводить в рассмотрение те же планы.

Интересовала мощность мн-ва всех планов.
Итого, по одной всего таблице (вернее, по одной связке таблиц) у нас есть куча планов, ОК (пару десятков от силы после предварительного отсеивания негодных планов).

При этом, сей набор планов один и тот же для нескольких сотен (или тысяч) всевозможнейших отчётов по аналитике.
Это ПРОСТЕЙШУЮ мысль я не могу донести до тебя уже пол-года.


S>И хрен вы построите "один, оптимальный план" по историческим данным — тупо потому, что "оптимальность" плана зависит от значений параметров.

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

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


S>А они, в отличие от исторических данных, каждый раз разные.

Зато код оценки планов и скана таблиц один и тот же.
Что и требовалось.

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

V>Не "лишнюю", а "единственную".
V>Я задавал прямой вопрос — "сколько таких таблиц в базе?"
Опять за рыбу деньги. Ок, мы добавили в базу одну таблицу, по которой есть два индекса и полтора плана..
Это никак не меняет ситуацию — остальные таблицы как были, так и остались, и запросы по ним как были, так и остались.

V>По твоей версии их должно быть сотни, т.е. мощность мн-ва всех планов ты оценил на пару порядков больше, чем я.
Конечно. Сотни самых разнообразных таблиц.

V>Бог с тобой.
V>В реальности видов orders многие десятки, иногда больше сотни.
V>Каждый из них живёт в своей уникальной таблице.
V>Т.е. умножай на сотню сходу.
Отлично, спасибо за аргумент в мою пользу.

V>В таблице documents — зависит от.
V>Ну пусть даже 5-6.
V>Эти таблицы единственные в своём роде.
И как раз по этим таблицам никаких запросов не гоняется. Зачем их вообще обсуждать?
V>По "исходникам" никакая аналитика не гоняется.
Именно по ним и гоняется. Потому что в "движениях" уже никакой аналитики нету.
V>Которые в показанной промышленной схеме строятся минимум на порядок быстрее, чем в случае собирания аналитики из сотен таблиц в ваших наколенных поделках.
V>В том числе потому, что трудоёмкость оценки всех планов в сотню раз меньше.
Я так и не понимаю, каким волшебным образом тут ускорится какая-то аналитика, когда её вообще не построить по этой усечённой таблице.
Мне она вообще не интересна — отчётов, в которых нужно вместе учитывать и заказы и акты инвентаризации, в реальном бизнесе не бывает.
Отчёты строятся ровно по тем самым заказам, ровно одного вида, который интересует. Потому что только там есть привязка ко всяким аналитикам типа менеджера по продажам, кодам скидки, и прочим вещам, нужным нам для оперативной оценки деятельности. У каждого сотрудника есть экран контроля, на котором показано то, что для него вынесено в KPI.
У продажников — продажи; у логистиков — доставки; у сборщиков — отгрузки; у HR-ов — текучесть; у ОТИЗ — процент ФОТ, у директоров филиалов — всё вместе.
И всё это нужно показывать не за 2017, а мгновенное значение на сегодня.

V>При этом, сей набор планов один и тот же для нескольких сотен (или тысяч) всевозможнейших отчётов по аналитике.
V>Это ПРОСТЕЙШУЮ мысль я не могу донести до тебя уже пол-года.
Просто эта мысль — неверна.

S>>И хрен вы построите "один, оптимальный план" по историческим данным — тупо потому, что "оптимальность" плана зависит от значений параметров.

V>Но к сегодняшнему дню ты хоть понял, почему код оценки плана растёт от листьев к корню или еще нет? ))
Я вообще вот эту фразу не понимаю. Было бы здорово увидеть, как выглядит вот этот "код оценки плана" на псевдокоде.
Потому что кто-то из нас двоих не понимает, как вообще устроен такой код. Хорошо, если я — будет интересно чему-то научиться.

V>Т.е. понимаешь ли ту простую весчь, что если даже к основному join добавили некоторый join со справочными данными и даже если выгодней сначала ограничить выборку через справочник (у которого есть только суррогатный ключ), то код оценки трудоёмкости скана по этому основному join будет тот же? И что код выборки тоже будет тот же, бо у нас есть лишь два варианта — сначала сканить таблицу движений или сначала таблицу документов.
Что такое "трудоёмкость скана по основному join"? И "код выборки" получается существенно разным для случая, когда мы сначала делаем join справочника с документом, а потом с движениями, или когда сначала движения с документом, а потом уже со справочником.
Мы же хотим этот код сделать специфичным и оптимизированным, а не делать вызов "делегата в цикле", чтобы отфильтровать ненужные записи справочника.
Обобщённый код исполнения запросов уже и так есть в SQL Server.
"Планом" запроса у нас будет что-то типа вот такого:

foreach(city in cityNameIndex.IndexSeek(cityName))
  foreach(document in documentsByCityIndex.IndexSeek(city.ID))
  {
    var s = 0;
    foreach(movement in movementsByDocumentIndex.IndexSeek(document.ID))
      if(movement.skuID == skuID) 
        s+= movement.Amount;
    yield return (document.ID, s) 
  }
}

Для других значений skuID и cityName мы для тех же трёх таблиц и того же запроса можем породить вот такой вот план:

int s;
foreach(movement in movementsBySkuIndex.IndexSeek(skuID))
{
  if(movement.DocumentID != prevDocumentID)
  {
    if (cityByIdIndex.IndexSeek(documentsByIdIndex.IndexSeek(prevDocumentID).cityID).Name == cityName)
      yield return (prevDocumentID, s) 
     s=0;
  }
  s+= movement.Amount;
}

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

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

V>>Не "лишнюю", а "единственную".
V>>Я задавал прямой вопрос — "сколько таких таблиц в базе?"
S>Опять за рыбу деньги. Ок, мы добавили в базу одну таблицу, по которой есть два индекса и полтора плана..
S>Это никак не меняет ситуацию — остальные таблицы как были, так и остались, и запросы по ним как были, так и остались.

Индексов зато на порядок меньше.


S>И как раз по этим таблицам никаких запросов не гоняется.

Как раз по этим таблицам и гоняется.


S>Зачем их вообще обсуждать?

Тебе неудобно?


V>>По "исходникам" никакая аналитика не гоняется.
S>Именно по ним и гоняется.

В наколенных поделках разве что.


S>Потому что в "движениях" уже никакой аналитики нету.

Тут нужен пример такой востребованной аналитики, что нужны исходники док-тов.

Потому что в промышленных системах бывает даже еще более циничный подход: вот прямо в той таблице Documents всё и хранится.
Просто есть еще 3-4 slave-таблицы с т.н. "аттрибутами", для хранения доп. полей, которые не вошли в дефолтную разметку таблицы Documents.
Как думаешь, зачем так делают?


S>Мне она вообще не интересна — отчётов, в которых нужно вместе учитывать и заказы и акты инвентаризации, в реальном бизнесе не бывает.

ОМГ ))
В той таблице хранится среди прочего тип док-та, разумеется.
И весь необходимый набор полей для 99% всей требуемой оперативной аналитики (по текущему периоду).


S>Отчёты строятся ровно по тем самым заказам, ровно одного вида, который интересует.

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

Если же сводить все типы заказов к одной таблице, то мы получим огромной ширины избыточный агрегат, который в большинстве полей хранит просто NULL.
Опять же, код валидации превращается в ад и Израиль (С), бо для некоторых типов заказов некоторые поля из такой "объединённой таблицы" могут быть NULL, какие-то нет и т.д. и т.п.

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

Gt_>>>>да уже все показывал и детально разжевывал чем функция на дотнете отличается
Gt_>>>>http://www.rsdn.org/forum/flame.comp/7153190.1
IB>В том топике, вы бесславно слились, так и не пояснив, к чему это все было. И вот опять..

чувак, ты не отличаешь декларативные конструкции от итеративных, что толку тебе в третий раз пояснять?

Gt_>>там вставка итеративных жава команд в декларативную конструкцию спаркового датафрейма.
IB>То есть, декларативная конструкция отдельно, интерактивная обработка результата декларативного вызова — отдельно. Иными словами, пример опять не про то.

то есть твой примитивный размум не воспринимает ни код ни русскую речь. я написал "вставка итеративных жава команд в декларативную конструкцию" и все равно бестолку. декларативного вызова.

Gt_>> то самое о чем толдычит alex_public, что не надо нас ограничивать куцым декларативным sql из нескольких команд.
IB>О чем вы талдычите — понятно, не понятно в чем вас сиквел ограничивает.

а ты попробуй подсунуть ML библиотеку сиквелу. в реальной жизни никому даже в голову не придет засовывать ML либу в сиквел, все решения сводятся в патерн — тупой сторидж отдает данные внешней проге. и все потому что в первую очередь нет никакой разницы, внешняя прога или .net процедура.

IB>Вот опять. Как мы выяснили, спарк отлично работает с sql, зачем что-то кроме SQL в декларативной части? То что можно выполнить императивный код по результатам запроса уже восемь раз обсудили, зачем интерактив при выполнении самого запроса?

вставка в декларативную конструкцию дает больше возможностей, позволяет использовать развесистые либы внутри механизмов датафрейма. самое очевидный пример — либы могут нативно оперировать развесистыми объектами, тогда как sql ... а sql без анала не натянуть на объекты библиотеки.

Gt_

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

Gt_>вставка в декларативную конструкцию дает больше возможностей, позволяет использовать развесистые либы внутри механизмов датафрейма. самое очевидный пример — либы могут нативно оперировать развесистыми объектами, тогда как sql ... а sql без анала не натянуть на объекты библиотеки.

Вот и еще один КО появился, плавали в бигдата, знаем. Как там с ACID?
Мы ведь тут «убогий SQL» обсуждаем, а не паралельную обработку данных на дистрибютед стораджах. Получается та же песня: а вы можете на .NET написать драйвер? Или еще хуже: заставить SQL сервер картинки процесить.
Всему свое применение и не надо перетягивать одеяло.

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

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

V>Тут нужен пример такой востребованной аналитики, что нужны исходники док-тов.
Я, возможно, не понимаю термина "исходники". Чем они отличаются от самих документов?
Примеры аналитики я привёл — каждой службе интересно что-то своё.

V>Потому что в промышленных системах бывает даже еще более циничный подход: вот прямо в той таблице Documents всё и хранится.
V>Просто есть еще 3-4 slave-таблицы с т.н. "аттрибутами", для хранения доп. полей, которые не вошли в дефолтную разметку таблицы Documents.
V>Как думаешь, зачем так делают?
Ну, это штука известная. Не справляются с DDL, поэтому делают решения, которые хреново работают с точки зрения производительности, зато можно сэкономить на написании однообразного кода.
V>ОМГ ))
V>В той таблице хранится среди прочего тип док-та, разумеется.
V>И весь необходимый набор полей для 99% всей требуемой оперативной аналитики (по текущему периоду).
Что-то мне подсказывает, что в угаре спора сейчас кто-то изобретёт схему E-A-V имени Тенцера.

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

V>Если же сводить все типы заказов к одной таблице, то мы получим огромной ширины избыточный агрегат, который в большинстве полей хранит просто NULL.
V>Опять же, код валидации превращается в ад и Израиль (С), бо для некоторых типов заказов некоторые поля из такой "объединённой таблицы" могут быть NULL, какие-то нет и т.д. и т.п.
Отлично. Вот то ли дело ваша идея — хранить все типы заказов в одной таблице.
V>Т.е., если изнасиловать доменную модель по предлагаемому тобой варианту, то сразу огребаем в затратах на ручном обслуживании эмулируемой доменной модели внутри "нейтрального" к домену агрегата. ))
Я вообще не понимаю уже, о каком таком "предлагаемом мноЙ" варианте идёт речь, и о каких затратах на ручное обслуживание идёт речь.
И какой вариант вы предлагаете, уже тоже не понимаю. Сначала вроде бы была отдельная "таблица движений", по которой не надо никаких запросов делать, кроме вставки, и там хранится только минимум информации, т.к. критичной является скорость "проведения операции".
Потом внезапно оказалось, что все данные хранятся в этой одной таблице, и по ней же строятся все запросы. Надо полагать, это для того, чтобы испортить статистику движка и не дать ему правильно оценить селективность предикатов. А, ну и чтобы избежать хранения нуллов в sparse атрибутах, у нас ещё добавлены три-четыре таблицы для right outer join.
Прямо всё сразу, красота.

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

V>>Индексов зато на порядок меньше.
S>С чего бы?

С ненужности.
Доп. поля в документах-исходниках в 90% случаев не нужны для аналитики, поэтому по ним нет ограничений и нет индексов.


V>>Как раз по этим таблицам и гоняется.
S>Всё, я потерял нить рассуждений.

Отож.


S>Как устроена база? В ней что, осталось три таблицы, по которым и гоняются все запросы?

По которым гоняется львиная доля вызываемых запросов.

В остальных таблицах среднее кол-во индексов приближается к 2-м от силы.


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

Уже получилось.


V>>Тут нужен пример такой востребованной аналитики, что нужны исходники док-тов.
S>Я, возможно, не понимаю термина "исходники". Чем они отличаются от самих документов?
S>Примеры аналитики я привёл — каждой службе интересно что-то своё.

V>>Потому что в промышленных системах бывает даже еще более циничный подход: вот прямо в той таблице Documents всё и хранится.
V>>Просто есть еще 3-4 slave-таблицы с т.н. "аттрибутами", для хранения доп. полей, которые не вошли в дефолтную разметку таблицы Documents.
V>>Как думаешь, зачем так делают?
S>Ну, это штука известная. Не справляются с DDL, поэтому делают решения, которые хреново работают с точки зрения производительности, зато можно сэкономить на написании однообразного кода.

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

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

С твоим подходом "каждому документу по таблице, каждой таблице по 15 индексов" это всё не взлетело бы низачто и никогда. ))


V>>В той таблице хранится среди прочего тип док-та, разумеется.
V>>И весь необходимый набор полей для 99% всей требуемой оперативной аналитики (по текущему периоду).
S>Что-то мне подсказывает, что в угаре спора сейчас кто-то изобретёт схему E-A-V имени Тенцера.

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


V>>Агащазз. Видов документов-заказов всегда более одного.
V>>В моей схеме достаточно будет перечислить типы участвующих типов док-ов для выборки данных, в твоей же схеме сам запрос будет меняться, бо будет меняться набор участвующих в запросе таблиц.
S>Ну, лично я с таким не сталкивался. С интересом посмотрю на такую реализацию, в которой поддерживаются настолько разные виды документов-заказов, что они потребуют прямо разных таблиц.



S>И при этом всё ещё будут интересны в рамках какого-то одного отчёта.

V>>Если же сводить все типы заказов к одной таблице, то мы получим огромной ширины избыточный агрегат, который в большинстве полей хранит просто NULL.
V>>Опять же, код валидации превращается в ад и Израиль (С), бо для некоторых типов заказов некоторые поля из такой "объединённой таблицы" могут быть NULL, какие-то нет и т.д. и т.п.
S>Отлично. Вот то ли дело ваша идея — хранить все типы заказов в одной таблице.

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

А ты предлагаешь и от доменной модели отказаться, устроив из таблиц свалку и профита никакого взамен не дал.
Твои предложения бессмысленны более чем полностью, и не только не имеют технической ценности, но просто вредны: усложняют разработку и поддержку, резко просаживают производительность.
Добавить новый тип документа? — это переписать пол-базы.
Посчитать аналитику? — не забыть пройтись по сотне таблиц с 15-ю индексами в каждой (С).

Это всё нерабочие схемы.
Да, я помню, что ты хвастался тем, что ЗАСТАВЛЯЛ такие схемы работать.
Но это всё write-only.
Один раз написать и всю жизнь молиться. ))
Костяка нет, всё рыхлое, в каждой группе сущностей собственные произвольные правила/наработки.
При столкновении с реальностью, в которой нужно постоянно что-то допиливать сугубо из-за прикладных нужд, оно всё сыпется как карточный домик.

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

D>Вот и еще один КО появился, плавали в бигдата, знаем. Как там с ACID?

а у вас негров линчуют.
кстати и с acid у хадупов все много лучше чем у майкрософт сиквела. типичный dwh на майкрософте выдает неконсистентную кашу на блокировочном уровне read committed, тогда как у меня в хадупе клиент всегда данные видит консистентно.

D>Мы ведь тут «убогий SQL» обсуждаем, а не паралельную обработку данных на дистрибютед стораджах. Получается та же песня: а вы можете на .NET написать драйвер? Или еще хуже: заставить SQL сервер картинки процесить.
D>Всему свое применение и не надо перетягивать одеяло.

в этой ветке речь о посыле alex_public о том что sql обрезав доступ на низкий уровень застыл в развитии. я это вижу тоже. вижу как рядышком уже гораздо элегантней соединили декларативный и итеративные миры. sql не развивается, а spark уже и на дата гридах ignite запускают и на касандре и на монге.

Gt_

Здравствуйте, alex_public, Вы писали:
_>Это и будет тот самый тупой for в лоб.
Добро пожаловать в обсуждение

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

.
Там представлены разные мнения на тему того, что и как понятнее.
vdimas, например, указывает на некорректность кода — по краям-то у нас тёмная каёмка.
Можно попробовать написать корректный код на "тупом for в лоб" и посмотреть, останется ли он столь же понятным, как и select from.

_>Этот пункт по умолчанию подразумевается во всех возможных подходах, так что его явная запись в нашей дискуссии — это просто бесполезная потеря времени.
Ок, принято. С переполнениями можно относительно легко побороться в каждом из подходов — например, приведя первое слагаемое к long.

_>Угу, меняем в нашем for арифметические операторы языка на интринсики для SIMD оптимизации или добавляем OpenACC директивы для ускорения на GPU.
Я с удовольствием посмотрю на конкретный пример c4-фильтра с интринсиками и OpenACC.
Они, кстати, взаимно совместимы? Или мне надо собирать екзещник отдельно под каждую целевую архитектуру?

_>Эм, а откуда у нас вообще взялась работающая функция Select? Напомню, что мы говорим о случае, когда готовой библиотеки алгоритмов нет и надо писать всё самому.
Например, иы пишем её сами. Минимальная работоспособная функция Select состоит из четырёх строчек, и её достаточно для того, чтобы прогнать функциональные тесты.
То есть суммарно у нас примерно столько же кода (плюс-минус лапоть), сколько и в "тупом императивном for", только этот код разазан по двум местам.

_>Или быть может ты реально считаешь, что идея написать ручной рантаймовый разбор AST — это и есть "пишем максимально понятный и короткий код"?
Нет, ручной рантаймовый разбор AST — это трудная (по крайней мере для меня) задача.
Но тут есть нюанс:
1. Мы откладываем её решение до момента, когда нам известно, где в коде узкое место. Это позволяет нам лучше использовать ограниченные ресурсы.
2. Если программа состоит из чего-то большего, чем однократный вызов одного алгоритма фильтрации (а обычно так и бывает), то наши инвестиции в оптимизацию "ручного рантаймового разбора AST" начинают окупаться, т.к. они делаются один раз. А расставлять интринсики и директивы надо в каждом цикле вручную.

_>Если говорить об оптимизаторах SQL (это отдельная тема, ортогональная генераторам SQL по DSL), то мне не очень понятно почему ты считаешь, что они возможны только в реализации через Linq? Это помимо того, что есть большой вопрос в необходимости подобных оптимизаторов вне СУБД.
Не обязательно через сам Linq. Но подход будет точно таким же — оптимизатору нужно видеть выражения, из которых собран запрос, а не просто "штуки, которые я могу склеить".
Если вы возьмётесь починить sqlpp так, чтобы он умел хоть что-то подобное linq2db, вам придётся построить те же самые Expression Trees, которые строит компилятор C#, только вручную.
И точно так же сворачивание этих деревьев придётся отложить до рантайма, потому что заранее неизвестно, что и куда придёт.
Ну, или у вас будет комбинаторный взрыв, когда на N nullable-параметров вы будете статически генерировать 2^N деревьев (ну, или сразу стейтментов)

_>Так некий абстрактный "взрослый движок в сервере приложений" в теории "может" это обнаружить или же есть конкретный движок, который вот таких образом на практике оптимизирует вот этот конкретный пример?
Да, linq2db выбрасывает дегенеративные джойны.
Вот, например:

   using (var db = new DbOrderTests())
            {
                var allOrders = from oi in db.OrderItems
                                group oi by oi.OrderId into og
                                from o in db.Orders.Where(q=>q.Id == og.Key).DefaultIfEmpty()
                                select new { OrderId = og.Key, Amount = og.Sum(oi => oi.Amount), o.Counterparty, o.CreationDate };
                var orderProjection = from a in allOrders select a.OrderId;
                foreach (var id in orderProjection)
                    Console.WriteLine(id);
            }

В сервер уезжает вот такой вот SQL:

SELECT
    [t2].[OrderId] as [OrderId1]
FROM
    (
        SELECT
            [t1].[OrderId]
        FROM
            [OrderItems] [t1]
        GROUP BY
            [t1].[OrderId]
    ) [t2]

При этом если я попробую материализовать не orderProjection, а allOrders, то исполнится запрос вместе с джойном:

SELECT
    [t2].[OrderId] as [OrderId1],
    [t2].[c1] as [c11],
    [q].[Counterparty],
    [q].[CreationDate]
FROM
    (
        SELECT
            [t1].[OrderId],
            Sum([t1].[Amount]) as [c1]
        FROM
            [OrderItems] [t1]
        GROUP BY
            [t1].[OrderId]
    ) [t2]
        LEFT JOIN [Orders] [q] ON [q].[Id] = [t2].[OrderId]

_>Ну на мой взгляд это естественно полный бред, но я пожалуй не буду особо спорить в этом направление, т.к. далёк от реалий энтерпрайзной разработки — возможно там действительно подобное считается нормой.
Энтерпрайз ни при чём. Любая задача достаточно большого размера требует командной работы. Никто не будет ждать, пока один джедай напишет монолитный код на 100к строк.
Будет работать как минимум команда, а зачастую и не одна. А командная работа — это разделение обязанностей. Роскоши иметь лапшерезку, в которой есть одна функция main, теперь почти ни у кого нету.
Потому и библиотеки становятся востребованы те, которые не запрещают композицию.

_>А вот ты пытаешься писать решения просто "сверху". И это получается в случае наличия готовых фреймворков, библиотек и т.п. Но при этом в случае отсутствия таковых и в силу наличия привычки такого написания резко наступает ступор. Как это случилось с банальным примером двоичного поиска в массиве целых чисел — ведь его правильный (с разбором выражения предикатов и т.п.) код для Linq так и не появился в данной темке...
Вы продолжаете хитрить. Покажите мне задачу, в которой возник этот "пример двоичного поиска в массиве целых чисел".
Если мы попробуем начать решать прикладную задачу (а не задачу доказать невозможность двоичного поиска в linq), то там не факт, что двоичный поиск вообще возникнет.
В лучшем случае возникнет задача "быстро найти элемент по ключу", где "двоичный поиск по отсортированному массиву" будет только одним из вариантов решения.
Возможно, при решениии этой задачи на С++ двоичный поиск окажется самым идиоматическим.
А при решении на С# запросто может оказаться, что .ToDictionary()[42] будет более наглядным решением. И заодно более эффективным, чем .Sort().BinarySearch(42).


S>>А вот здесь

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

приведён пример кода, который хоть и использует рефлексию, но не требует выполнения процесса каждый раз с нуля.
_>Собственно опять же отсутствие разбора AST и отсутствие необходимости в Linq (оно здесь опять же исполняет никчемную роль "запускателя лямбд").
Тут важен не столько сам linq, сколько идеология разделения алгоритма обхода и алгоритма обработки "окрестности".

_>Т.е. вот весь этот твой код (кстати довольно любопытный) абсолютно элементарно записывается на C# без использования Linq (но с использованием рефлексии, причём в данном случае ты хорошо показал, как можно оптимизировать её тормознутость). И будет выглядеть даже короче и понятнее.


_>Опять же глупости — мы же измеряли, что по производительности на одной машине Mongo быстрее классических РСУБД (там же изначально была заточенность на работу в оперативной памяти). Так что 1000 серверов Mongo понадобится только для такой задачи, которую на РСУБД вообще невозможно решить (ну во всяком случае в классическом режиме, не переделывая её в аналог nosql с ручным шардингом).
А размер данных-то был какой? Просто "заточенность на работу в оперативной памяти" хороша тогда, когда памяти больше чем данных.
Просто я могу подключить к серверу HDD размером в 10TB, и SQL Server прекрасно справится с задачей в 8GB RAM благодаря могучему оптимизатору.
А монга на той же железке с тем же размером склеит ласты, т.к. "там же изначально была заточенность на работу в оперативной памяти". Придётся срочно шардить, попилив на 250 восьмигигвыых машинок.
Можно будет для интересу сравнить стоимость такого парка с десятитерабайтным винчестером.

_>>>Ну т.е. в точности подход OpenACC/Numba. ))) Кстати, кинь ссылочку глянуть на реализацию.
S>>https://devblogs.nvidia.com/hybridizer-csharp/
S>>https://archive.codeplex.com/?p=cudafy

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

_>Ну так этот пример и не умеет максимальной производительности (достигаемой вручную), а умеет только автовекторизацию компилятора и плюс распараллеливание внутреннего for ( ) по системным потокам с помощью OpenMP. Если бы мы захотели максимально производительности, то пришлось бы записать этот for руками...
Ухты! Только что video++ приводился как пример суперкрутого оптимального кода, и вдруг... Впрочем, там в дотнетном топике коллеги и Eigen обсирают — говорят, хуже только WPF.

_>А это буквально тоже самое, что и абзацем выше, только зачем-то в ненужной Linq обёртке. Если записать всё тоже самое так (без всякого Linq):
_>

_>B = map2d(A, a=>a[-1, 0] + a[1, 0] + a[0, 1] + a[0, -1]) / 4);
_>

_>то будет намного симпатичнее.
Ну, то есть дело вкуса.

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

Gt_>чувак, ты не отличаешь декларативные конструкции от итеративных, что толку тебе в третий раз пояснять?
То есть опять слились, жаль...

Gt_>то есть твой примитивный размум не воспринимает ни код ни русскую речь.
Я просто пытаюсь опуститься до вашего уровня, признаюсь, пока получается не очень.

Gt_> я написал "вставка итеративных жава команд в декларативную конструкцию" и все равно бестолку. декларативного вызова.
А я написал, что это было понятно с самого начала, и что это не проблема и не имеет никакого отношения к проблемам SQL-я. alex_public утверждал, что проблема именно в декларативной части, и что SQL-ю нужны императивные возможности, чтобы улучшить качество запросов. Вы вроде как с ним солидарны. Так вот я по прежнему жду объяснений, хоть от кого-нибудь, как это может помочь.

Gt_>а ты попробуй подсунуть ML библиотеку сиквелу.
Так спарк же, вы же сами приводили пример. Или имеется ввиду MSSQL? https://docs.microsoft.com/en-us/sql/advanced-analytics/tutorials/machine-learning-services-tutorials?view=sql-server-2017

IB>>Вот опять. Как мы выяснили, спарк отлично работает с sql, зачем что-то кроме SQL в декларативной части? То что можно выполнить императивный код по результатам запроса уже восемь раз обсудили, зачем интерактив при выполнении самого запроса?
Gt_>вставка в декларативную конструкцию дает больше возможностей, позволяет использовать развесистые либы внутри механизмов датафрейма. самое очевидный пример — либы могут нативно оперировать развесистыми объектами, тогда как sql ... а sql без анала не натянуть на объекты библиотеки.
Вы похоже, опять не поняли вопрос. Перечитайте еще раз внимательно.

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

Gt_>кстати и с acid у хадупов все много лучше чем у майкрософт сиквела. типичный dwh на майкрософте выдает неконсистентную кашу на блокировочном уровне read committed, тогда как у меня в хадупе клиент всегда данные видит консистентно.
Я понимаю, что возможно вам в детстве read committed нанес какую-то тяжелую эмоциональную травму, так что до сих пор глаз дергается, но не надо проецировать свои подростковые комплексы на всю индустрию. У типичного хранилища на mssql, будь то OLAP или OLTP, нет ни каких проблем с консистентностью, про ваш хадуп, однако, такого утверждать не могу, учитывая ваши ответы в форуме.

Gt_>в этой ветке речь о посыле alex_public о том что sql обрезав доступ на низкий уровень застыл в развитии. я это вижу тоже.
Да, как собачка, все понимаю, но объяснить не могу...

Gt_> вижу как рядышком уже гораздо элегантней соединили декларативный и итеративные миры. sql не развивается, а spark уже и на дата гридах ignite запускают и на касандре и на монге.
Я вижу как вы с завидным постоянством употребляете умные слова в произвольном порядке, не очень понимая какое отношение они имеют к обсуждаемой теме.

Gt_>> я написал "вставка итеративных жава команд в декларативную конструкцию" и все равно бестолку. декларативного вызова.
IB>А я написал, что это было понятно с самого начала, и что это не проблема и не имеет никакого отношения к проблемам SQL-я. alex_public утверждал, что проблема именно в декларативной части, и что SQL-ю нужны императивные возможности, чтобы улучшить качество запросов. Вы вроде как с ним солидарны. Так вот я по прежнему жду объяснений, хоть от кого-нибудь, как это может помочь.

чувак, тебе не 14 лет, тебе уже ничего не поможет. ты проведя в ИТ десятилетия не понимаешь примитивные конструкции в коде, ты не понимаешь русскую речь. вот я три раза уже написал что в коде у меня "вставка итеративных жава команд в декларативную конструкцию", на третий раз ты это осознал ? ты понимаешь чем это от последовательного выполнения отличается ?


Gt_>>а ты попробуй подсунуть ML библиотеку сиквелу.
IB>Так спарк же, вы же сами приводили пример. Или имеется ввиду MSSQL? https://docs.microsoft.com/en-us/sql/advanced-analytics/tutorials/machine-learning-services-tutorials?view=sql-server-2017

имелся ввиду мсскл. ссылка именно о том, о чем я говорю, внутрь не подсунуть. выкручиваются синтаксическим сахаром, через sp_configure 'external scripts enabled'. т.е. внешний скрипт выкачивает к себе данные и там обрабатывает, в реальных проектах смысла ноль. так и останется еще одной бесполезной фичей, т.к. тратить процессорное время и память сервера мсскл в эпоху 10 GBs сетей никто не станет. так и продолжат выкачивать на соседнюю машину.

IB>>>Вот опять. Как мы выяснили, спарк отлично работает с sql, зачем что-то кроме SQL в декларативной части? То что можно выполнить императивный код по результатам запроса уже восемь раз обсудили, зачем интерактив при выполнении самого запроса?
Gt_>>вставка в декларативную конструкцию дает больше возможностей, позволяет использовать развесистые либы внутри механизмов датафрейма. самое очевидный пример — либы могут нативно оперировать развесистыми объектами, тогда как sql ... а sql без анала не натянуть на объекты библиотеки.
IB>Вы похоже, опять не поняли вопрос. Перечитайте еще раз внимательно.

я вопрос понял, загвоздка в том что твой примитивный мозг не видит разницы между последовательным выполнении и внутри конструкции. у sql и соответственно у spark sql нет аналогичной конструкции.
у sql субд самое близкое понятия курсора, т.е. декларативно объявляется курсор, а потом в отдельной конструкции по мере фетча запускаем итеративные команды. со спарком та же фигня, можно объявить датасет через sql, но для каждого объекта датасета выполнить итеративный код понадобиться отдельная конструкция с лямдой. через sql никак.

Gt_

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

S>Если вы возьмётесь починить sqlpp так, чтобы он умел хоть что-то подобное linq2db, вам придётся построить те же самые Expression Trees, которые строит компилятор C#, только вручную.

Собственно, в sqlpp это предусмотрено, только в языке нет Expression Tree, а потому это заменено на ручной дсл, структура которого соответствует SQL, типа where(), filter(), join(). Вот эту часть, теоретически, можно траслировать на лету во что угодно.

Gt_>>кстати и с acid у хадупов все много лучше чем у майкрософт сиквела. типичный dwh на майкрософте выдает неконсистентную кашу на блокировочном уровне read committed, тогда как у меня в хадупе клиент всегда данные видит консистентно.
IB>Я понимаю, что возможно вам в детстве read committed нанес какую-то тяжелую эмоциональную травму, так что до сих пор глаз дергается, но не надо проецировать свои подростковые комплексы на всю индустрию. У типичного хранилища на mssql, будь то OLAP или OLTP, нет ни каких проблем с консистентностью, про ваш хадуп, однако, такого утверждать не могу, учитывая ваши ответы в форуме.

не скрою, в свое время меня разобрал истерический хохот, когда мсскл на read committed начал выдавать больше записей чем было в реальности в любой момент времени.
типичное DWH на мсскл грузят миллионы строк не в одной транзакции, часто каждую таблицу грузят параллельно со своей транзакцией, часто коммитят порциями по N строк. в результате во время загрузки пользователи видят неконсистетную кашу, в то время как snapshot в хадупе позволяет выдавать полностью консистентные данные в любой момент времени. в том числе и в момент перестройки витрины.

Gt_>>в этой ветке речь о посыле alex_public о том что sql обрезав доступ на низкий уровень застыл в развитии. я это вижу тоже.
IB>Да, как собачка, все понимаю, но объяснить не могу...

тебе нет. тут программист нужен (с)

Gt_

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

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

Gt_>имелся ввиду мсскл. ссылка именно о том, о чем я говорю, внутрь не подсунуть. выкручиваются синтаксическим сахаром, через sp_configure 'external scripts enabled'. т.е. внешний скрипт выкачивает к себе данные и там обрабатывает, в реальных проектах смысла ноль.
Вы опять делаете далеко идущие выводы из не правильных предположений. Хоть речь изначально была вообще не про MSSQL, я привел ссылку на пример, как можно использовать ML с SQL-ем, в MSSQL, хотя вы утверждали что так не получится. Кто там и чего себе выкачивает — детали реализации, о них поговорим отдельно, если до этого дело дойдет.

Gt_>я вопрос понял,
Если поняли, зачем тогда с завидным упорством отвечаете на что-то другое? Как студент из анекдота, который выучил только про блох, а в билете ему лягушка попалась.

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

Gt_> у sql и соответственно у spark sql нет аналогичной конструкции.
Gt_>у sql субд самое близкое понятия курсора, т.е. декларативно объявляется курсор, а потом в отдельной конструкции по мере фетча запускаем итеративные команды.
Вы, похоже, многого не знаете про SQL. Пойдите, поучите функцию APPLY, например, потом продолжим.
Хотя, это опять же не имеет отношения к обсуждаемому вопросу.

Gt_>со спарком та же фигня, можно объявить датасет через sql, но для каждого объекта датасета выполнить итеративный код понадобиться отдельная конструкция с лямдой. через sql никак.
Повторюсь, вы либо не очень хорошо знаете SQL, либо вообще не очень хорошо понимаете, что такое SQL, либо прилипи к какой-то не очень удачной реализации.

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

Gt_>не скрою, в свое время меня разобрал истерический хохот, когда мсскл на read committed начал выдавать больше записей чем было в реальности в любой момент времени.
А вот если бы не ржали, а мозг включили, то могли бы понять, что это хорошо описанное и понятное поведение RC уровня изоляции, которое понятно как обходить в зависимости от сценария. И это не является секретом ни для кого еще с восьмидесятых, когда уровни изоляции были представлены.
Если у вас это вызывает смех, то могу только посочувствовать.

Gt_>типичное DWH на мсскл грузят миллионы строк не в одной транзакции, часто каждую таблицу грузят параллельно со своей транзакцией, часто коммитят порциями по N строк. в результате во время загрузки пользователи видят неконсистетную кашу,
Это только если разработчики не понимали что делали или инструмент ипользовался не по назначению.

Gt_> в то время как snapshot в хадупе позволяет выдавать полностью консистентные данные в любой момент времени. в том числе и в момент перестройки витрины.
В каком именно хадупе? HBase, например, обладает точно такми же RC, как любой блокировочник и "A scan is not a consistent view of a table. Scans do not exhibit snapshot isolation." (с)

Gt_>тебе нет. тут программист нужен (с)
Да я не претендую, вы хоть кому-нибудь объясните.

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

IB>Вы, похоже, многого не знаете про SQL. Пойдите, поучите функцию APPLY, например, потом продолжим.
Есть подозрение, что делаются тонкие намёки на то, что применение APPLY к дотнетному коду влечёт за собой маршалинг, т.к. использовать SQL-данные "напрямую" в дотнетной функции нельзя.
Не вполне понятно, насколько этот маршаллинг дорогой — в контексте всей стоимости исполнения запроса.
Тем не менее противопоставляется именно чисто-джавная реализация, в которой можно просто передавать (и принимать обратно) ссылки на объект, не занимаясь копированиями между управляемой и неуправляемой памятью.

Потенциальных решений этой проблемы (если она измеримо значима) могла бы стать чисто-managed реализация RDBMS, либо тщательное перепроектирование всего слоя интеграции дотнета в сиквел с учётом последних разработок в джите и дотнеткоре.
Впрочем, второе — единственное, что могло бы помочь сделать первое. Неоднократно думал о такой штуке, и всё время кажется, что всё упрётся в невозможность нормальной работы с данными, упакованными в "дисковом" формате.
Существующий код сиквел-сервера же там ничего не копирует вплоть до отдачи клиенту (ну, или там table spool), классический select просто бежит по таблице/индексу, отображённой в память, и читает данные как ((DecimalPtr*)(currentRec+currentRec.Offsets[-11]).

Ну, вот и в дотнетной команде проснулись и осознали. Так что есть шансы и в управляемом коде копирования подсократить.