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

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

_>Чтобы не считать, никаких проблем с рекурсивными лямбдами у C# нет.
Есть. Точно такая же как и у линка, точнее даже та же самая проблема.

_> А вот у Linq есть (и то вроде уже решили как раз только что).
Не только что, а с самого начала и точно так же, так как проблема та же самая.

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

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

_>Это было про вообще или про конкретный случай, который мы обсуждали?
И про вообще и про конкретный случай.

_> Потому что в данном конкретном случае я не вижу вообще никакого контракта (ну кроме разве что контракта на "вызов функции двух параметров" ) в Linq коде.
А он есть. Благодаря ему можно переписать выражение на query comprehensions, что гораздо читаемее.

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

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

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

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

Не особо нужны для клиентского кода на linq. Правильно. Возможности декомпозиции в linq сто раз круче CTE, а рекурсивные запросы нужны раз в сто лет и под них всегда можно накидать хранимку или запрос на голом SQL.

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

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

Зачем?

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

У нас есть такие ракеты, но мы вам их не покажем.

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

НС>Не особо нужны для клиентского кода на linq. Правильно. Возможности декомпозиции в linq сто раз круче CTE, а рекурсивные запросы нужны раз в сто лет и под них всегда можно накидать хранимку или запрос на голом SQL.

Table Function, которую linq провайдеры воспринимают как таблицу с параметрами.

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

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

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

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

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

Это так называлась библиотека ORM? ))
Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
А это вообще возможно физически? ))
Боюсь, у вас там был просто слой DAL, а весь "ORM" выполнялся строго ручками.


V>>Аргумент.
S>Конечно. Вот мы же с вами обсуждаем — и прямо на ходу выясняется, что никаких проблем обойтись без рукопашной генерации идентификаторов нету.

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


S>Вы просто не понимали тогда (да и сейчас с трудом понимаете) некоторые нюансы T-SQL.

Вы просто напрашиваетесь на грубый посыл, бо было написано:

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

http://www.rsdn.org/forum/flame.comp/7090301.1
Т.е. еще задолго до того, как ты возбудился, шла речь ровно о таких возможностях.

Да и, вообще, семейство ф-ий IDENTITY даётся в любом учебнике по T-SQL одним из первых.
Но хрен с ними, с учебниками.
Ты зачем-то уже третий раз пытаешься мне доказать, что я не знал о такой возможности.

Тут два варианта:
— или ты меня тупо троллишь;
— или совершенно не в состоянии понимать прочитанное, т.е. а как с тобой вообще общаться?

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


V>>Т.е., всерьёз считаешь приведённый тобой сниппет чем-то сложным?
S>Ну, вы же не знали, что он возможен.

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


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

Выделенное где???
Ты точно понимаешь, что есть roundtrip?


S>Вот, цитирую:
S>

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

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

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

"За раз" — это в одном запросе или за один вызов хранимки.
Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
Ну вот документы каждый по нескольку сотен строк.
А еще и несколько док-тов за раз.
Я потому и приписал там же "кошмар" со смайликом, а ты уже 3-й пост подряд не понимаешь — почему.
Медленно соображаешь...

А теперь сам гвоздь программы: контекст был — отзывчивость GUI, асинхронность.
В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
Каждое выделенное слово — ключевое.

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


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

Я многократно в обсуждении тыкал тебя в то, что ты разговариваешь на каком-то своём языке.
Ведь все ходы записаны — вернись и ВНИМАТЕЛЬНО почитай, что я писал.
Ведь форум — это прекрасно.
Твои представления о предмете меняются, а написанное мною — нет.
И у тебя появляется чудесная возможность с каждым прочтением открывать для себя что-то новое.


S>Но с вами, пока что, как правило, всё наоборот — как только вас ловишь на очевидной чуши

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

Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
— если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
— SQL-серверы не работают поверх ISAM (работают поголовно, пусть даже местами назвали VSAM);
— важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
— мне трижды пришлось объяснять тебе, что транзакция биржи и транзакция БД — разные вещи, и что кол-во сообщений не равно кол-ву транзкаций как биржи, так и в БД;
— накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
— спорил до хрипоты с приведёнными цифрами о скорости работы современных дисков.

Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
Выдаёт скорости в точности как указано в спецификации.
вот на этой материнке:
https://ru.gecid.com/mboard/gigabyte_z370p_d3/

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


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

Бог с тобой.
Абсолютно все разы, когда я находил твои "не разобрался" получались как побочный эффект в результате МОЕЙ самозащиты от ТВОИХ нападок.
Ну блин, ты же совсем херню уже пороть изволишь, что мне уже остаётся тщательно трассировать за тобой ход твоих же мыслей, как за теми двоечниками, что мне регулярно присылают друзья/знакомые на "подтянуть". Так я у тех тоже должен тщательно пройтись по ИХ рассуждениям (не моим) с целью найти участок, на котором "всё поломалось".
Блин, да после первого же такого раза, где посторонний человек нашёл дыру в твоих мозгах вместо тебя, надо было убиться апстену от невыносимого стыда...
Не потому что дыра, а потому что за несколько возвратов и итераций ты так и не нашёл её самостоятельно...
Ну этож пипец, как по мне.
Я общаюсь с недееспособным коллегой.

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

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

Подмена понятий.
Операция вставки является "слабонагруженной", а не таблица.
Но в этом и была цель, собсно.

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


S>и там, действительно, все интересные планы можно один раз прописать заранее.

Дык, я именно об этом с самого начала и говорил — что по таблице движений кол-во планов запросов априори невелико.
Это если брать оперативные данные.
А если брать исторические, т.е. неизменяемые, то таким данным можно поставить атрибут "read only" и тогда для львиной доли сценариев уже в compile-time можно найти не просто "всевозможные планы", а именно лучшие или даже один лучший. Данные-то уже все есть.

Похоже, эта мякотка до тебя в прошлый раз по каким-то причинам не дошла.
Ты так и не асилил проанализировать предложенную схему в комплексе, т.е. как она себя ведёт на всех основных сценарях.
Зря.
Я по-прежнему весьма рекомендую.
Тру-перфекционист испытает профессиональное удовлетворение, обещаю.


S>А вся краткосрочная аналитика делается по orderDetail и Orders

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


S>ровно как в той самой схеме Northwind, которую вы пытались критиковать.

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



S>Если что-то продолжает оставаться непонятным — спрашивайте, я поясню.

Да всё понятно, хосподя.

Здравствуйте, vdimas, Вы писали:
V>Это так называлась библиотека ORM? ))
Не "библиотека ORM", а просто ORM. Object-relational mapper.
Там была адская смесь метаданных в коде приложения, метаданных в таблицах в базе, и метаданных в виде собственно объектной модели.
V>Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
Ядро — было абстрактным. На основе этого ядра писались "наши прикладные типы".
100% кода — на дельфях.
V>А это вообще возможно физически? ))
Отож.

V>Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
А где я говорил о незнании IDENTITY? Я наглядно вижу ваше непонимание, как правильно готовить батчи для MS SQL.
V>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
Ну вот, продолжаете тупить. Вполне себе реальный сценарий. Именно так всё и работало. Ничего военного — подготовили команду, отправили на сервер.
Вижу, для вас эта простая идея представляет непредставимую сложность.

V>Ну вот документы каждый по нескольку сотен строк.
V>А еще и несколько док-тов за раз.
Отож. Вы что, правда думаете, что отправить 50 килобайт данных по сети — это что-то невообразимое?
V>В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
И в чём проблема? Подождать 3 секунды после нажатия на "Save"?
V>Ну, реально, вот прямо отсуюда дай мне ссылку, плиз, именно на мою чушь.
Ссылки искать среди тысяч ваших сообщений мне неинтересно. Из того, что осталось в памяти:
— что EC2 Амазона были обычными серверами, которые надо было заказывать за три дня, и только в 2009 их перевели на виртуализацию
— что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса
— что Skype for Business использует проприетарный протокол вместо стандартного SIP/RTP
— что-то там про ресайз страниц в SQL Server

V>Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
V>- если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
о да, тут вам повезло — поймали на разнице терминологий.

V>- важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
Это вы, похоже, не понимаете фундаментальной природы вещей. Не бывает таких бизнесов, стоимость которых меньше их оборота. Я вам даже формулы приводил, как первокласснику. Вы продолжаете тупить, и верить в бизнесы, у которых есть потребность в миллион транзакций в минуту, но при этом зарабатывают они на этих транзакциях столько, что не могут себе позволить $50k на железо.

V>- накладные расходы при передаче в другой процесс можно игнорировать по сравнению с "тут устаревший набор представлений о дисках";
Ну, вы же так и не опровергли мои аргументы. В ответ — какой-то бред про "прерывания".

V>Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
V>https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
V>Выдаёт скорости в точности как указано в спецификации.
V>вот на этой материнке:
V>https://ru.gecid.com/mboard/gigabyte_z370p_d3/
Ну, почему бы не скачать софтинку и не запустить её? Поделитесь результатами — общественность будет вам благодарна.
Интересует random mixed read/write, очередь можете любого размера.

V>Подмена понятий.
V>Операция вставки является "слабонагруженной", а не таблица.
Понятия "нагруженность операции" не существует.
V>Но в этом и была цель, собсно.

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

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

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

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

S>Здравствуйте, vdimas, Вы писали:
V>>Это так называлась библиотека ORM? ))
S>Не "библиотека ORM", а просто ORM. Object-relational mapper.

Но мы обсуждали либы/фреймворки.


S>Там была адская смесь метаданных в коде приложения, метаданных в таблицах в базе, и метаданных в виде собственно объектной модели.
V>>Что, прям абстрактная от конкретных ваших прикладных типов и прямо на Дельфях?
S>Ядро — было абстрактным. На основе этого ядра писались "наши прикладные типы".
S>100% кода — на дельфях.
V>>А это вообще возможно физически? ))
S>Отож.

Ясно, невозможно.
Всё ручками.
Как и все остальные в те года.


V>>Т.е., твоё поучение должно было трансформироваться из упрёка в незнании IDENTITY в упрёк в незнании о наличии такой хрени как батчей, не?
S>А где я говорил о незнании IDENTITY? Я наглядно вижу ваше непонимание, как правильно готовить батчи для MS SQL.

О! Всё-таки батчи!

Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...


V>>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
S>Ну вот, продолжаете тупить.

Продолжаю настаивать, а не тупить.
Потому что не кластер с ценой транзакций 0.1$ за штуку, а обычный комп, с ценой транзакций примерно 0.00001$ за штуку.


S>Вполне себе реальный сценарий. Именно так всё и работало. Ничего военного — подготовили команду, отправили на сервер.

И залипли на 3-10 секунд.
Я б уволил.


S>Вижу, для вас эта простая идея представляет непредставимую сложность.

Да какая там сложность?
Это ж то самое решение в "лоб", от которого мне всю жизнь приходилось уходить.
И не от хорошей жизни приходилось, заметь, а из-за проживания в реальном мире, а не в мире сферических коней в вакууме.

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


V>>Ну вот документы каждый по нескольку сотен строк.
V>>А еще и несколько док-тов за раз.
S>Отож. Вы что, правда думаете, что отправить 50 килобайт данных по сети — это что-то невообразимое?

Я не думаю, я знаю, (бо постоянно наблюдал) что это задержки на ровном месте по состоянию на 20+ лет назад.
Поэтому, в популярных промышленных системах никто так не делал, разумеется, т.е. никто не отправлял многокилобайтные батчи на сервак.

Документ отправлялся на сервак построчно или группами строк (в асинхронном UI, которое как раз стало мегапопулярно именно во второй половине 90-х, с развитием клиент-сервера и трехзвенки).

Просто в Дельфи всего этого не было, разумеется.
Дельфи — это как обратная сторона Луны... там жили и работали инопланетяне.
Там, наверно, даже другие физические законы были. ))


V>>В твоём случае надо ожидать ответ от сервака, прежде чем продолжить редактировать в "синхронном" режиме строчки накладной, отправляя на сервак их обновлённые версии.
S>И в чём проблема? Подождать 3 секунды после нажатия на "Save"?

Это если ты один подключённый к серваку, то 3 секунды.
А так-то и десяток секунд аж бегом.
За этот же десяток секунд уже можно обслужить следующего клиента.
Кароч, от клиентского сценария ты малость далёк, я уже обращал на это твоё внимания.
Достаточно того, что ты всю дорогу делаешь акценты на сложности/важности именно серверной части.
Отнюдь, серверная часть никогда не бывает сложной от слова вообще (там есть лишь сложность поддержки, но это побочные эффекты языка SQL и отдельный разговор, почему SQL так радостно переезжает на клиента + LINQ).
В любом случае, именно информационная сложность БД-части до клиентской никогда не дотягивает.
Даже в полноценной трехзвенке, а не в примазываемом к трехзвенке HTTP-сценарии.
Клиент диктует вообще все сценарии работы с серваком, бо ради него (клиента) всё и затевалось.


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

Во-первых, это было не в этом обсуждении, а в другом.
Я проявил незнание того, как обстояли дела конкретно с AWS.
Зато знал, как обстояли дела с виртуализацией вообще, бо я в ней живу — в среднем несколько часов в день с 2001-го года, бо характер работ такой.
Во-вторых, я, в отличие от, признал за собой невладение некоторой информацией.

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

А ларчик там просто открывался — на момент 2006-2008-хх лет вменяемой виртуализации в Linux не было.
Она появилась в сыром виде в 2011-м и в более менее нормальном виде вот недавно — в 2013-м.

До этого была технология qemu, т.е. технология полной эмуляции аппаратуры.
Кто помнит самые первые версии VirtualBox, тот должен понимать, о чём речь.
Сравнивать с уже вышедшим полноценным Hyper-V сей кошмар было нельзя.
Это были разные вселенные.

На "той стороне" технологий был еще такой гипервизор Xen.
Одно но — с ним всё было не просто в те года, нужно было патчить исходники ядра Linux и кучи системных сервисов для работы с ним.
Поэтому, на Xen хорошо ложился лишь на такой сценарий, когда поставщик услуг собирает свою пропатченную сборку с самостоятельно собранным из сырцов ядром, основными сетевыми службами, веб-серваком, скриптовым языком и каким-нить MySQL. Вот такой сценарий был мега-популярен — когда тебе дают уже преднастроенную специально собранную под Xen виртуалку, в которой лишь веб-сервак+скрипт+sql+ftp/sftp и шаг вправо-влево банально недоступен.

Но это ж "не оно", верно?
Произвольный бинарный образ на "этом" не запустишь.
А на чём запустишь (на RHEL под AWS), то вдвойне "не оно".
Почему не оно?
Потому что на тот момент была совсем уж сильная зависимость генерируемого кода от опций компилятора, в которых указывалось поколение целевых процессоров.
Для сравнения, собранная Генту на начало 2000-х у меня работала минимум на 30% быстрее чем RHEL. Генту собиралась по-месту на целевой проц, а не на (упаси хосподи) на 486-й, как тогда собирался RHEL. Почему Генту и вызывала такой интересо тогда.

Но Генту и прочие сборки Линукс, включая собственные (я участвовал одно время в разработке и поддержке одной из сборок), — это всё на Xen не жило от слова никак и ни в коем случае.
А пользовать qemu — это или обман клиентов или жуткая неэффективность, тут на выбор, как сие назвать.

Однако, когда я по твоей ссылке (спасибо, кста) увидел цену "аренды" в пересчёте на одноядерный проц с 1700 MHz тактовой (при том, что у меня на столе уже стоял комп с 3.2 GHz), то всё встало на свои места.
Паззл у меня в голове сошёлся — да, таки qemu.
Какой кошмар. )))
У богатых свои причуды.


S>- что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса

Разумеется. Каждая запись в shared memory в Windows вызывает прерывания ОС, чтобы пометить ссотв. страницы памяти как "грязные".
Потому что нет такого понятия "просто shared memory" в Windows, есть технология маппинга файлов в память.
И пометка страниц для последующей обязательной синхронизации с диском — это азы азов сей технологии.
Даже если ты не указал конкретный файл для маппинга, то cистема тебе выделит область в system paging file.
Но суть происходящего не изменится.
RTFM!


S>- что Skype for Business использует проприетарный протокол вместо стандартного SIP/RTP

Это ты указал, что используешь Skype for Business.


S>- что-то там про ресайз страниц в SQL Server

И что там? ))

Ну, т.е., в ЭТОМ обсуждении найти мою "чушь" у тебя не получилось.
Итого, голосновность, так и запишем.


V>>Потому что перечислить твою бесконечную чушь мне вовсе не сложно:
V>>- если ISAM — то речь непременно о файловой базе, индексы непременно хранятся отдельно и без транзакций;
S>о да, тут вам повезло — поймали на разнице терминологий.

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


V>>- важна только стоимость транзакций, а то, что железо при этом будет стоить дороже стоимости всего бизнеса заказчика — не важно; ))
S>Это вы, похоже, не понимаете фундаментальной природы вещей. Не бывает таких бизнесов, стоимость которых меньше их оборота. Я вам даже формулы приводил, как первокласснику. Вы продолжаете тупить, и верить в бизнесы, у которых есть потребность в миллион транзакций в минуту, но при этом зарабатывают они на этих транзакциях столько, что не могут себе позволить $50k на железо.

Тем не менее, обычный современный серверный бокс ценой до 2000 зелени справляется с сотней тыс транзакций в секунду (описанной "сложности" их по твоей ссылке).
Вот и прикинь стоимость транзакции за ~5 лет работы этого сервака.
Она выходит на несколько порядков меньше озвученных тобой цифр.
И кто тут первоклассник?
Разделить два числа уже не в состоянии.


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

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


V>>Кстате, не далее месяца назад я поставил себе похожий девайс от обсуждаемого:
V>>https://www.dns-shop.ru/product/855ee22dac8f3330/250-gb-ssd-m2-nakopitel-samsung-960-evo-mz-v6e250bw/
V>>Выдаёт скорости в точности как указано в спецификации.
V>>вот на этой материнке:
V>>https://ru.gecid.com/mboard/gigabyte_z370p_d3/
S>Ну, почему бы не скачать софтинку и не запустить её? Поделитесь результатами — общественность будет вам благодарна.

Дык, я сходу скачал несколько программ для теста диска и погонял их.
Скриншоты прислать?


S>Интересует random mixed read/write, очередь можете любого размера.

Ага, уже mixed read/write?
А соломки не постелить? ))
А чего же не sequential read для очереди длиной свыше сотни?
Неудобно?
Зато SQL-серваку очень удобно на 99% сценариев.

Ну и, главное замечание, что эти "голые скорости" чтения с диска в любом случае получаются уже выше, чем даже в случае расположения файлов базы на RAM-диске, т.е. узким местом современные SSD-диски уже не являются.
Узкое место — сама СУБД.
Об этом и есть всё это обсуждение, если ты не заметил до сих пор.

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

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

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

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

С чего бы это?

S>Возможность "нырнуть на низкий уровень" не означает возможности встраивать ассемблер в SQL. В том же linq эта возможность предоставляется путём разрешения писать свои Where, GroupBy, Join и прочие SelectMany.
S>Вот там-то можно и разгуляться, как хочется. В том числе и отмаршаллить запиненную ссылку на 2d массив в неуправляемый код, чтобы он там сделал всё, что угодно.
S>Это — хороший, правильный способ.

Ну так "голый C#" относительно Linq — это по сути и есть низкий уровень ("ассемблер"). Т.е. идеологически тут как раз всё правильно. А вот убогость конкретной реализации данной абстракции — это уже другой вопрос.

S>В SQL, если вас не устраивает встроенный агрегат, вы регистрируете пользовательский агрегат. Недостаток здесь — в существенной разнице языков программирования. Примерно так же, как во времена Visual Basic: между теми, кто создавал компоненты, и теми, кто их использовал — технологическая пропасть. Тот же самый Delphi предоставлял значительно более пологую learning curve, потому что язык написания и использования компонентов — один и тот же.

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

S>Вот идеальная замена SQL как раз должна давать возможность "допиливать" серверный код, не теряя декларативности и прочих вещей. Ведь те же агрегаты неспроста так ограничены — они так устроены, что крайне трудно написать их несовместимым с параллелизацией способом.

А вот у Hadoop почему-то никаких проблем нет... Ну т.е. ограничения конечно же есть (типа модели MapReduce), но они не сильно ограничивают программиста.

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

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

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

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

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

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

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

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

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

И? Где обоснование этого бреда?

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

Ну раз ты хочешь сравнивать развитие PL/SQL с развитием C#, то тогда будет точно так же корректно сравнить и развитие SQL с C#. И сделать аналогичный вывод о неактуальности SQL...

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

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

Да, способы есть, но все они дико уродливые в сравнение с решением на PL/SQL из пары простейших строчек.

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

Знать то как раз многие знают, т.к. они про него опубликовали много чего. А вот использовать где-то снаружи нельзя, т.к. нет поддерживающих СУБД. Из общедоступных его по идее можно прикрутить без потери функциональности разве что к Hadoop, но вряд ли они будут тратить ресурсы на это.

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

_>>Что там неудобного то? Что вместо var/auto надо указывать явный тип создаваемой функции? Это так ужасно? )))
IB>не явный тип, а делегат с явным типом, что сильно мусорит код и затрудняет понимание того что написали.

Хы. А многие (я правда к таким не отношусь) считают что использование var/auto при объявление переменных наоборот ухудшают понимание кода. )))

_>>Чтобы не считать, никаких проблем с рекурсивными лямбдами у C# нет.
IB>Есть. Точно такая же как и у линка, точнее даже та же самая проблема.

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

_>> А вот у Linq есть (и то вроде уже решили как раз только что).
IB>Не только что, а с самого начала и точно так же, так как проблема та же самая.

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

_>>Создавать библиотеку (например SQL EDSL или другой EDSL) с помощью такого подхода возможно не очень просто. А вот пользоваться ей потом одно удовольствие (местами удобнее Linq).
IB>Чем же удобнее, если это точно такой же линк, только рукопашный? ))

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

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

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

Ну покажи пример, как оно будет более читаемо для обсуждаемой здесь задачи.

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

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

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

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

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

Я в данной теме уже приводил примеры более удобных, функциональных и эффективных реализаций. Причём как Linq для коллекций, так и Linq для СУБД.