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

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

IB>SELECT ROW_NUMBER() OVER(ORDER BY name) as id, STRING_SPLIT(REPLICATE(name + ', ', count), ', ') name FROM table
IB>

IB>Не, так не правильно, забыл, что STRING_SPLIT табличная функция, а не строковая, правильно так (но сути это не меняет):
IB>

IB>SELECT ROW_NUMBER() OVER(ORDER BY [value]) id, [value] [name] FROM table OUTER APPLY string_split(RTRIM(REPLICATE([name] + ' ', [count])), ' ')
IB>

Склеить строки и потом парсить их? Очаровательная идея...

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

IB>SELECT t1.id, t2.name FROM number t1 JOIN table t2 ON t1.id BETWEEN 1 AND t2.count
IB>

IB>На линке должно быть еще проще, там есть средства генерации данных, join такой же.

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

_>>Гугл использует BigTable, от которой собственно и зародилось "движение" NoSQL.
IB>Ну а до BigTable они активно гоняли MySQL. Причем, что гугл, что яндекс — не лучший пример в данной дискуссии, так как задачи у них (мы же про поиск?) сильно отличаются от того, для чего предназначался SQL.
IB>Там поиск нужен полнотекстовый, почти нет джойнов и всем крымский мост положить на целостность данных.

Да, у них сильная специфика, с этим никто не спорит. Речь как раз и была о том, что не вся специфика хорошо выражается через SQL.

_>>Что-то ты сам себе противоречишь. Твоя же цитата: " В итоге получилось то что получилось, а Кодд много лет спустя написал статью Fatal Flaws in SQL, где как раз критиковал несоответствие теории и фактической реализации SQL-я в RDBMS".
IB>У нас похоже опять проблемы, с тем кто и что написал. )) Мысль была в том, что не смотря на то, что язык получился кривой, теория на которой он таки базировался, все равно появилась раньше и позволила формально доказать, что кроме этого языка никакого доступа к внутренностям не надо. Иными словами, из того, что язык вышел неудачным, вовсе не следует, что его делали не имея никакой теоретической базы.

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

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

_>>Уже 10 раз (причём включая конкретные примеры) было показано, что множество задач решаемых с помощью SQL является подмножеством задач, решение которых задаётся произвольным императивным кодом.
IB>Да, только все эти задачи удивительным образом лежать за пределами сценариев, для которых SQL предназначен.

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

_>>Потому что кроме указанногo по ссылке решения можно захотеть получить ещё и такое https://en.wikipedia.org/wiki/Apache_Phoenix (кстати, применяется в Cloudera, которая как раз отвоёвывает у РСУБД мир Корпоративных Хранилищ Данных) и такое https://en.wikipedia.org/wiki/Apache_Trafodion (что там говорили про транзакции?) и даже такое https://www.opencypher.org. Причём всё это заводится поверх одного и того же hadoop кластера.
IB>Ну, то есть мы таки наворачиваем SQL и прикручиваем транзакции поверх новомодных хадупов, что и требовалось доказать, собственно ))

Ну во-первых не обязательно SQL (как ты сам видел по ссылкам). А во-вторых я вообще то изначально писал, что совершенно не против такого подхода (и даже вполне его одобряю). Но только при условии, что мы не обрезаем доступ на нижний уровень (собственно hadoop api в данном случае).

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

IT>>>Поясни и приведи примеры других вариантов в более мощных языках. Мне интересен сам подход и как он реализуется компилятором. Кстати, что за языки такие?
_>>Да возьми любой язык с приличным метапрограммированием, отрабатывающем в процессе компиляции.
IT>Ну назови хотя бы один. И про примеры других вариантов не забудь.

Да полно их. Тот же Nemerle (из знакомой тебе платформы .net) должен справиться. Или Scala (из мира JVM). Или Rust из нативного мира.

IT>>>Зачем? Я правда без понятия. Оно появилось, чтобы решить какую-нибудь проблему или как обычно, потому что это сделали не мы?
_>>Мдааа....
IT>Ну вот и славненько. Главное, что по существу претензий нет.

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

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

IB>>Тем не менее, можно извернуться и на SQL пользуясь особенностями конкретной реализации.
IT>Никаких конкретных реализаций. CTE наше всё.

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

P.S. Кстати, как раз поэтому отсутствие рекурсии в Linq генераторах SQL выглядело особо заметно.

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

_>>Особенно хорошо эти твои фантазии видны например здесь https://www.cloudera.com/more/customers.html.
НС>И что я там должен был увидеть?

Конкретные шаги крупного бизнеса по замене РСУБД на nosql решения (причём это список для всего лишь одного конкретного недешёвого продукта).

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

_>>Так зависит от способа задания выражений. Например при таком http://rsdn.org/forum/flame.comp/7060147.1

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

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

Только тогда уж это будет не в linq, а вместо linq. )))

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

_>>Так зависит от способа задания выражений. Например при таком http://rsdn.org/forum/flame.comp/7060147.1

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

(скрытый код) способе не вижу никаких проблем. Причём такой способ доступен в очень многих языках программирования, включая и C#.
IB>То есть предлагается написать собственный интерпретатор и задавать рекурсию в выражении через него? Радикальненько )) Можно и по проще, но не так просто как хотелось бы:

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

IB>Собственно, проблема с рекурсией в одном выражении в C# https://blogs.msdn.microsoft.com/ericlippert/2006/08/18/why-does-a-recursive-lambda-cause-a-definite-assignment-error/

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

Хотя это не единственный вариант решения проблемы рекурсивной лямбды. Например в C++ можно сделать более эффективный (т.к. и std::function и делегаты имеют оверхед) вариант благодаря наличию полиморфных лямбд:

auto fac = [](int n) {
  auto impl = [](int n, auto self) {
    if (n < 2) return 1;
    return n * self(n - 1, self);
  };
  return impl(n, impl);
};

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

IB>Решение для linq через Y-combinator https://blogs.msdn.microsoft.com/madst/2007/05/11/recursive-lambda-expressions/
IB>То есть на linq можно писать рекурсивные выражения. Но делается это не просто. Однако причина этого не в linq как таковом, а в ограничениях языка. Откуда такие ограничения, можно почитать по первой ссылке.

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

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

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

Немерле мог бы, но не сможет. Скала и Раст тоже так шоб шибко популярные, то не шибко. А больше назвать ты ничего не в состоянии.

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

Что-то я не припомню ни одного твоего аргумента против, кроме, конечно, я этого не понял, поэтому это не так.

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

_>P.S. Кстати, как раз поэтому отсутствие рекурсии в Linq генераторах SQL выглядело особо заметно.

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

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

_>Только тогда уж это будет не в linq, а вместо linq. )))

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

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

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

Y combinator задолго до линка придумали, причем, емнип, в Хаскеле.

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

_>Конкретные шаги крупного бизнеса по замене РСУБД на nosql решения (причём это список для всего лишь одного конкретного недешёвого продукта).

А, еще один дядька в Киеве. ОК.

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

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

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

S>В двухзвенной системе у пользователей прав на insert и update на эти таблицы нет, а есть только право выполнения хранимой процедуры.

А да.
Что мешает при коннекте к базе в обход приложения вызывать эти хранимые процедуры?

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

V>А да.
V>Что мешает при коннекте к базе в обход приложения вызывать эти хранимые процедуры?
Ничего не мешает. Но при этом нарушения целостности не произойдёт: не получится "подправить" остатки, не записав "движения".

Здравствуйте, vdimas, Вы писали:
V>Какой кошмар. ))
V>А если в док-те порядка 250-ти строк?
То будет SQL на 250 строк. Чего тут такого?
Вы что, думаете, что делать 250 вызовов .Execute() по одному insert() сильно быстрее, чем один вызов c 250 инсертами? Ну-ну.

V>На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.
Чушь какая. Примерно такую транзакцию отправляет на сервер любой ORM с change tracking.

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

V>В моих системах я делал так:
V>- заводил для редактируемых док-тов временные таблицы уровня пользователя;
V>- клиент редактирует, программа периодически пачками скидывает данные на сервак приложений (сохранять построчно-синхронно на трехзвенке на той технике было просто нереально — полусекундные спотыкания раздражают), сервак приложений обновляет данные во временных таблицах сервака базы;
V>- при потере связи клиента с сервером приложений или сервера приложений с базой данных ничего страшного не происходит (это как раз разрабатывалось в те времена, когда надёжной связи не существовало в принципе, даже локальной, бо тогда был коаксиал);
V>- для сохранения док-та делаются простые insert into из временных таблиц в обычные;
V>- при отмене док-та, т.е. удалении без сохранения, сервак приложений возвращает этот ID в список свободных.

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

V>В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д.
Чушь какая. Я же показал код — где там "придумывание уникального ID для нового документа"?

V>У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
V>Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
Вот именно, что получилась она как побочный эффект от пятиколёсного велосипеда. Со стороны пользователей такой задачи не ставилось. Просто вы, коллега, слабо владели T-SQL, отсюда и нагромождение бессмысленностей.
Бывает, чо уж там. Я сам счастлив оттого, что написанный мною в 1995м код не сохранился — а то пришлось бы размазывать по лицу слёзы стыда.

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

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

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

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

V>>Какой кошмар. ))
V>>А если в док-те порядка 250-ти строк?
S>То будет SQL на 250 строк. Чего тут такого?
S>Вы что, думаете, что делать 250 вызовов .Execute() по одному insert() сильно быстрее, чем один вызов c 250 инсертами?

Я думаю, что достаточно подробно описал свою реализацию.
Вот как раз затем описал, чтобы мне не вменяли невесть что.
Но ты продолжаешь.


V>>На той технике (не мега-кластерной, а на простых пнях на 150 МГц тактовой) подобные подходы работали так себе.
S>Чушь какая. Примерно такую транзакцию отправляет на сервер любой ORM с change tracking.

Это уже после 2000-го года.
Никакая ORM в 96-97-х годах не жила.


V>>Да это обычные заморочки с популярными алгоритмами распределения памяти, они открыты и общедоступны, бери да пользуй.
S>Вот только незачем.

Аргумент.


V>>Не вижу здесь сложностей.
S>Пока что сложнее, чем приведённый мною текст.

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

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


S>Проще держать документ в памяти, и скидывать в сервер по кнопке Save.

Понятное дело, что проще. ))
На Бейсике писать тоже проще ровно в том же смысле — потому что ничего сложного не напишешь.


S>Если в процессе отправки произошёл сбой (что крайне маловероятно даже на коаксиале)

Кхмм...
А что же ты так часто напираешь на "сетевые файловые базы" и их недостатки?
Противоречим сами себе, аднака.


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

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


V>>В твоём же варианте в любом случае надо придумывать уникальный ID для нового док-та, потому что пользователь может редактировать несколько док-тов, возвращаться к ним и т.д.
S>Чушь какая. Я же показал код — где там "придумывание уникального ID для нового документа"?

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


V>>У меня было так — можно было выйти из проги, с другого компа зайти и продолжить редактировать док-ты.
V>>Такая функциональность получилась как побочный эффект от попыток борьбы с последствиями обрывов связи.
S>Вот именно, что получилась она как побочный эффект от пятиколёсного велосипеда.

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


S>Со стороны пользователей такой задачи не ставилось.

Со стороны пользователей задача вообще слабо ставится, примерно так: "надо, чтобы работала".
Правильно ставить задачу учили как раз меня.


S>Просто вы, коллега, слабо владели T-SQL, отсюда и нагромождение бессмысленностей.

Т.е., всерьёз считаешь приведённый тобой сниппет чем-то сложным?
Хосподя, убейся уже апстену, как можно так глупить-то который уже раз...
После целой россыпи высокоуровневых и не очень языков, которыми ПРИШЛОСЬ владеть в 90-х (вот такие были времена) — T-SQL — это детсад.
Даже более мощный (по тем временам) PL/SQL — тоже.

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

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


S>Бывает, чо уж там. Я сам счастлив оттого, что написанный мною в 1995м код не сохранился — а то пришлось бы размазывать по лицу слёзы стыда.

Конечно, бывает. В программировании полно случайных людей ошивается.
Этот перекос сугубо из-за ЗП.
Зато науку двигать некому.
Грамотные в своей предметной области люди массово переквалифицировались в неграмотных программистов.
С высоты птьичьего полёта — это большая беда.

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

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

_>>>Ага, я помню этот фееричный подход в сравнение производительности: возьмём для Linq алгоритм с логарифмической сложностью, а для императивного кода с линейной. И на логичный вопрос "а какого ...?" ответим какой-нибудь чушью в стиле: "ну если у нас в проекте изначально был линейный алгоритм, то переписывание его на логарифмический с помощью Linq можно осуществить быстрее, чем для императивного кода".
IB>>Ну почему же чушью, если это так и есть? )

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

Как правило, время и бюджет всегда ограничены. При бесконечном времени и бюджете разницы в технологиях нет. Более того, и в квалификации разных людей тоже нет различия.

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