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

V>Это уже после 2000-го года.
V>Никакая ORM в 96-97-х годах не жила.
Наша — жила. Так и называлась — "Торговля 97".

V>Аргумент.
Конечно. Вот мы же с вами обсуждаем — и прямо на ходу выясняется, что никаких проблем обойтись без рукопашной генерации идентификаторов нету.
Вы просто не понимали тогда (да и сейчас с трудом понимаете) некоторые нюансы T-SQL.
Теперь мне пытаетесь задним числом рассказать, что такой код 20 лет назад не мог работать. При этом я его пробовал исполнять, а вы — нет; и внятных аргументов против него придумать тоже не можете. Увы.

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

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

V>Понятное дело, что проще. ))
Проще — значит надёжнее. Проще — значит быстрее в разработке, и можно использовать сэкономленное время на написание чего-то полезного.
S>>Если в процессе отправки произошёл сбой (что крайне маловероятно даже на коаксиале)
V>Кхмм...
V>А что же ты так часто напираешь на "сетевые файловые базы" и их недостатки?
V>Противоречим сами себе, аднака.
Вы, коллега, просто не понимаете, в чём состоят недостатки сетевых файловых баз. Не будем об этом — лучше давайте на пальцах разберём ваше непонимание сравнительных верятностей.
Вот смотрите: мы выполняем некоторую транзакцию — сохраняем документ (ну, или N документов). Если мы сохраняем его "из памяти", то на сервер уезжает пачка insert values. Если из "временной таблицы" (кстати, а как документ оказался во временной таблице?), то уезжает чуть меньшая пачка insert select.
Теперь сравним, чем отличается SQL в случае client-generated IDs vs Server-Generated. Только тем, что при Server-Generated на каждый документ добавляется 2 стейтмента — декларация переменной и её инициализация.
Ну, и как будут отличаться вероятности сбоя в том и в другом случае? Да никак. Они будут пренебрежимо малы — в локальной-то сетке. Там же объём пересылаемых данных — считанные килобайты. Всё влазит в несколько MTU; добиться обрыва TCP ровно в момент передачи — редчайшая удача. Скорее соединение порвётся в момент простоя, что будет обнаружено keepalive-heartbeat.

Вот если бы мы занимались тем способом Server-Generated идентификаторов, который вы зачем-то предположили — тогда да, у нас было бы n round-trips, и шансы словить обрыв в процессе этого медленного двустороннего обмена были бы значительно выше.

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

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


V>Т.е., всерьёз считаешь приведённый тобой сниппет чем-то сложным?
Ну, вы же не знали, что он возможен. Только что мне рассказывали о том, что не умеете записывать несколько master-records, и что обязательно потребуется раундтрип на клиента.
Вот, цитирую:

Я хорошо представляю себе как закинуть в одной операции одну строку из master и к ней несколько из slave без заведомого знания про ID master-а, но плохо представляю как закинуть за раз несколько строк master-a с соотв. привязанными slave без предварительного знания ID master-ов. Более того, в первом случае придётся еще озаботиться ожиданием ответа из вызова серверной процедуры

V>Хосподя, убейся уже апстену, как можно так глупить-то который уже раз...
Вот и я удивляюсь.

V>Почему остальные тебя терпят, но у тебя с самообладанием того-сь? )) Вы же тут все как на ладони, хосподя, видны насквозь. Как только вас ловишь на непонимании предмета,
Так вот было бы здорово, если бы получалось. Я люблю, когда мне указывают на пробелы в моих знаниях. Хоть что-то новое удаётся узнать.
Но с вами, пока что, как правило, всё наоборот — как только вас ловишь на очевидной чуши, вы пытаетесь резко передвинуть дискуссию в другую тему, в панической попытке найти хоть какой-то предмет, в котором ваш собеседник, возможно, не разобрался.

Здравствуйте, 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 здесь — более чистый синтаксис.
Особенно будет здорово, если потребуется усложнить задачу — скажем, трансформировать не весь массив, а какую-то его подобласть. Скажем, ограниченную набором прямых, заданных их уравнениями. Тогда лямбда-стайл превратится в нечитаемую лапшу из вызовов, а linq останется вполне читаемым.

Здравствуйте, alex_public, Вы писали:
_>Который вряд ли сможет эффективно подойти под все все возможные варианты использования. Скорее будет хорошо только на каком-то самом популярном сценарии.
Как раз наоборот. Вы не понимаете сути: такой подход позволяет разделить обязанности.
Кто-то хорошо разбирается в прикладном решении — знает, какие формулы нужно писать (например, какие ядра использовать для фильтрации в тех или иных условиях).
Кто-то хорошо разбирается в низкоуровневой математике — знает, как влияет выравнивание на cache hit ratio, понимает, как работает конвеер x64 и какие циклы стоит развёртывать, а какие — нет, и так далее.

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

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

И от их разработок начинают лучше работать все программы, а не только те, которые переписаны вручную.

Поэтому очень важно, чтобы код, написанный "прикладником", содержал как можно меньше лишних деталей. Например, для 2d-фильтрации важной является возможность задавать ядро. Порядок обхода элементов массива — лишняя подробность. Её пусть выбирает кто-то другой — например, программист, который пишет библиотеку 2d-фильтрации. Если он считает, что есть какие-то важные детали на этапе выполнения, то может встроить проверку и выбор в эту библиотеку (ну, например: есть Nvidia — конвертим в CUDA. Нету — фигачим через SSE3. Смотрим, сколько ядер у процессора, и пилим изображение на страйпы для одновременной обработки).

Пытаться переиграть такого программиста — это всё равно как водителя маршрутки в пробке обогнать: иногда возможно, но потребует чудовищных усилий, и всё равно 2 раза из 3х он приедет первым.

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

_>Питон нужен чтобы быстро (в смысле времени написания кода) и удобно решать задачи. C/C++ модули нужны чтобы этот код на Питоне быстро (в смысле машинного времени) получал требуемый результат. Это одна из оптимальнейших архитектур, применяемая очень много где (от игр и cad'ов, до суперкомпьютеров).

Как с питоном и с++, так тебе понятно. А если вместо питона и с++ подставить linq и sql, так сразу непойми что от тебя прёт.

Это ровно тот же принцип, что и в питоне & с++ — медленный язык нужен для связывания, что бы быстро получать требуемый результат.

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

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

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

Скорость подняли, это я про маппинг, стал быстр. С linq до сих пор пичалька. Им надо change tracker сапортить, lazy loading, eager loading, code first. Хомячки без этого уже не могут. Все это накладывает серьезные ограниечения на linq запросы. Bulk операции так и не появились, групировка часто работает из вон рук плохо.

Интереса ради я сделал этот проект https://github.com/linq2db/linq2db.EntityFrameworkCore
Немножко видна заинтересованность со стороны EF разработчиков и комюнити. По крайней мере вам не придется башлять за это http://entityframework-plus.net/, а нет недели не прошло сделали бесплатным. Возможно и из-за нас Говнокод еще тот.

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

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

Всё очень неоднозначно.

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

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

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

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

А причём тут C#, если я предложил сравнить развитие sql и pl/sql? )

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

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

IB>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
IB>

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

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

Ха, да даже тот же YQL (который от Яндекса, а не от Yahoo — и как они так лажанулись с названием?) уже выглядит намного лучше, чем SQL. )))

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

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

Что там неудобного то? Что вместо var/auto надо указывать явный тип создаваемой функции? Это так ужасно? )))

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

Чтобы не считать, никаких проблем с рекурсивными лямбдами у C# нет. А вот у Linq есть (и то вроде уже решили как раз только что).

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

Создавать библиотеку (например SQL EDSL или другой EDSL) с помощью такого подхода возможно не очень просто. А вот пользоваться ей потом одно удовольствие (местами удобнее Linq).

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

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

Это было про вообще или про конкретный случай, который мы обсуждали? Потому что в данном конкретном случае я не вижу вообще никакого контракта (ну кроме разве что контракта на "вызов функции двух параметров" ) в Linq коде.

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

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

Заходим на 10-ый круг? Вроде бы уже много раз обсудили что что является подмножеством чего...

Кстати, я вот в прошлый раз кидал тут ссылочку на статью, где одновременно применяется на одном и том же hadoop кластере (и одних и тех же данных, но на разных стадиях их обработки) и MapReduce запросы и Spark запросы и SQL (Hive/SparkSQL) запросы. Не хочешь попробовать провести всю описанную работу только на SQL? )))

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

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

Что бы отделить специфичное для конкретного языка.

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

Похожего возможно и нет, а вот лучше конечно же есть. )

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

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

Т.е. ты хочешь сказать, что CTE не нужно в РСУБД, правильно? )

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

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

Да, мне это не надо. Но по другим причинам. Моими рабочими (а не для самообразования или фана) языками в данный момент являются C++ и Python, плюс посматриваю на Rust, как на потенциальную замену C++. Как видно, никакого C# у меня нет, так что вопрос использования Liqn даже не стоит. Более того, в обоих указанных языках есть свои средства для работы с коллекциями и СУБД, гораздо более удобные, чем Linq.

D>Надо быстро за пару тактов склеить строки, а оптимизацией я как-то на досуге займусь.
D>Сэкономил на одном — просрал в 10 раз больше на другом. Так мне видится твой подход к работе с базами.

Мой подход? ))) Это какой же интересно?

D>Linq это чудо появившееся в мире языков. Желаю твоему закостеневшему мозгу прийти к этому утверждению побыстрее.

Ты про какой Linq, который для коллекций или для генерации SQL? Хотя они оба достаточно кривые...

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

Зачем мне делать что-то полезное для C#, которым я не пользуюсь? )))

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

Думаю что это как раз оптимальное разделение. Есть довольно много случаев (вот прямо у меня такое имеется и я там использую удобство Питона), когда скорость вообще не важна — там монстры типа EF, делающие всё сами, весьма удобны (ну на уровне доступного из C#). А когда требуется максимальная производительность, надо наоборот уходит на максимально низкий уровень (в случае текущих РСУБД это будет просто SQL, хотя на самом деле лучше бы ещё ниже, как во многих nosql решениях).

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

S>Здравствуйте, 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? )))
S>Чистая польза от linq здесь — более чистый синтаксис.

И в чём он более чистый? Замена "transform(data, d=>...)" на "from d in data group d by ..." выглядит наоборот, как синтаксическое замусоривание.

S>Особенно будет здорово, если потребуется усложнить задачу — скажем, трансформировать не весь массив, а какую-то его подобласть. Скажем, ограниченную набором прямых, заданных их уравнениями. Тогда лямбда-стайл превратится в нечитаемую лапшу из вызовов, а linq останется вполне читаемым.

С чего бы это? Если ты будешь использовать linq в том же стиле, что и выше, то это будут просто такие же лямбды и всё.

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

_>>Который вряд ли сможет эффективно подойти под все все возможные варианты использования. Скорее будет хорошо только на каком-то самом популярном сценарии.
S>Как раз наоборот. Вы не понимаете сути: такой подход позволяет разделить обязанности.
S>Кто-то хорошо разбирается в прикладном решении — знает, какие формулы нужно писать (например, какие ядра использовать для фильтрации в тех или иных условиях).
S>Кто-то хорошо разбирается в низкоуровневой математике — знает, как влияет выравнивание на cache hit ratio, понимает, как работает конвеер x64 и какие циклы стоит развёртывать, а какие — нет, и так далее.

Да, поэтому даже та библиотечка обработки видео сама использует несколько других библиотек, типа ускоренной SIMD алгебры. Но при этом все они живут в рамках одного базиса (языка C++).

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

Это ты что-то споришь с голосами в своей голове — я такого не высказывал.

S>В моём идеальном мире он тоже может всем этим заниматься, но не обязан. Есть возможность делегировать написание библиотечного кода людям, которые тратят годы на изучение и отладку всего этого хардкора. Они имеют возможность гонять алгоритмы фильтрации на широком спектре аппаратуры, замечать закономерности, и писать логику по выбору пути исполнения даже в тех ситуациях, о которых прикладник не имеет никакого понятия.

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

А вот в твоём идеальном мире (в котором доступ к СУБД реализуется даже не на SQL, а на чём-то ещё более высокоуровневом) как раз наоборот нет возможности этим заниматься, т.к. просто тупо нет доступа к ассемблерным инструкциям и всё.

S>И от их разработок начинают лучше работать все программы, а не только те, которые переписаны вручную.
S>Поэтому очень важно, чтобы код, написанный "прикладником", содержал как можно меньше лишних деталей. Например, для 2d-фильтрации важной является возможность задавать ядро. Порядок обхода элементов массива — лишняя подробность. Её пусть выбирает кто-то другой — например, программист, который пишет библиотеку 2d-фильтрации. Если он считает, что есть какие-то важные детали на этапе выполнения, то может встроить проверку и выбор в эту библиотеку (ну, например: есть Nvidia — конвертим в CUDA. Нету — фигачим через SSE3. Смотрим, сколько ядер у процессора, и пилим изображение на страйпы для одновременной обработки).

Если это реализовано как библиотека для моего языка программирования, то я всегда могу не только просто её использовать, но и подправить/надстроить в нужной мне специфике. А вот если это какая-то "безопасная среда" или "отдельный сервер с неким текстовым api", то тут уже ничего особо не исправить...

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

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

Здравствуйте, alex_public, Вы писали:
_>Да, поэтому даже та библиотечка обработки видео сама использует несколько других библиотек, типа ускоренной SIMD алгебры. Но при этом все они живут в рамках одного базиса (языка C++).
В таком случае вы хитрите, говоря, что "там внутри for". Возможность использования ускоренной SIMD алгебры напрямую связана с отказом от явного for в пользу лямбды.

S>>В моём идеальном мире он тоже может всем этим заниматься, но не обязан. Есть возможность делегировать написание библиотечного кода людям, которые тратят годы на изучение и отладку всего этого хардкора. Они имеют возможность гонять алгоритмы фильтрации на широком спектре аппаратуры, замечать закономерности, и писать логику по выбору пути исполнения даже в тех ситуациях, о которых прикладник не имеет никакого понятия.

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

Возможность "нырнуть на низкий уровень" не означает возможности встраивать ассемблер в SQL. В том же linq эта возможность предоставляется путём разрешения писать свои Where, GroupBy, Join и прочие SelectMany.
Вот там-то можно и разгуляться, как хочется. В том числе и отмаршаллить запиненную ссылку на 2d массив в неуправляемый код, чтобы он там сделал всё, что угодно.
Это — хороший, правильный способ.
В SQL, если вас не устраивает встроенный агрегат, вы регистрируете пользовательский агрегат. Недостаток здесь — в существенной разнице языков программирования. Примерно так же, как во времена Visual Basic: между теми, кто создавал компоненты, и теми, кто их использовал — технологическая пропасть. Тот же самый Delphi предоставлял значительно более пологую learning curve, потому что язык написания и использования компонентов — один и тот же.
Вот идеальная замена SQL как раз должна давать возможность "допиливать" серверный код, не теряя декларативности и прочих вещей. Ведь те же агрегаты неспроста так ограничены — они так устроены, что крайне трудно написать их несовместимым с параллелизацией способом.
_>А вот в твоём идеальном мире (в котором доступ к СУБД реализуется даже не на SQL, а на чём-то ещё более высокоуровневом) как раз наоборот нет возможности этим заниматься, т.к. просто тупо нет доступа к ассемблерным инструкциям и всё.
Доступ к ассемблерным инструкциям там будет, но не из уровня формулировки запросов, а из уровня "расширения движка".

_>Если это реализовано как библиотека для моего языка программирования, то я всегда могу не только просто её использовать, но и подправить/надстроить в нужной мне специфике.
В некотором смысле — да. Хотя все успешные примеры работают не так: в том же питоне numpy написана на совсем другом языке программирования, и умение её подправить/надстроить встречается среди пользователей numpy примерно 1 раз на 10000.

_>Главное чтобы был шанс, а пользоваться им будут только те, кому реально надо.
В таком раскладе шанс есть и сейчас — можно подать резюме в Редмонд, и если у вас реально хватит квалификации, чтобы написать что-то полезное в SQL Server, не сломав существующее, то вас, скорее всего, туда возьмут.

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

_>С чего бы это? Если ты будешь использовать linq в том же стиле, что и выше, то это будут просто такие же лямбды и всё.
Очень быстро превратятся в лапшу. Синтаксис Query Comprehension придумали не от того, что было нечего делать. Написали цепочки вызовов Where().GroupBy().OrderBy().ThenBy(), посмотрели, прослезились, и переписали на linq.

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

_>ОК, давай рассмотрим этот сценарий. Так каким образом его существование по твоему оправдывает подобную уникальную методику сравнения производительности кода? )))
Самым прямым.

_>А причём тут C#, если я предложил сравнить развитие sql и pl/sql? )
Ну зачем опять дурачком-то прикидываться? При том, что на примере C# я показал, как на самом деле выглядит развитие языка, в отличии от того, что происходит с pl/sql и аналогами.

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

_>Вот так уже похоже на правду. Хотя тебе для этого пришлось создавать дополнительную таблицу (по исходным данным ты решить задачку не мог).
да вы зануда. во-первых, как я уже сказал, это не совсем SQL задача, во-вторых, временную таблицу с id можно создать на лету, а в трерьих — вот без таблиц, временных таблиц и исключительно на ANSI SQL

with cte (name, [count])
as
(
    select * from names
    union all
    select name, [count] - 1 as [count]
    from cte
    where [count] > 1
)
select row_number() over(order by name) id, name
from cte
order by name

Смысл-то задачи в чем? показать, что sql не может? Может, и способов больше чем один.

_>Ха, да даже тот же YQL (который от Яндекса, а не от Yahoo — и как они так лажанулись с названием?) уже выглядит намного лучше, чем SQL. )))
Но пока кроме яндекса о нем никто не знает. Вот прикрутят его к какой-нибудь СУБД, тогда посмотрим.