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

V>>А сколько всего может быть вариантов плана у среднего запроса?
IB>Начнем с того, что средний запрос не интересен, но дело даже не в этом.

Более чем интересен.

V>>Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
IB>В целом да, количество счетное, только считать устанешь.

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

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


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

Во-во. Это зависит в том числе от объема данных и текущего состояния пересчитанных индексов (их актуальности).
На меньших данных индексы будут поактуальнее.


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

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

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


V>>И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
IB>Проблема только в том, что план запроса может зависеть от параметра

В этом месте ты забыл сделать паузу и представить происходящее. ))


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

Все возможные варианты уже известны в compile-time.
Вот у тебя в запросе участвует 5 таблиц через join (или его аналог/разновидность), вот у тебя идут ограничения только по 3-м из этих таблиц, у остальных 2-х есть только основной суррогатный ключ, бо это "справочники".
Эти взятые с потолка цифры — они даже с запасом для самых "ходовых" сценариев.
По каждой из других таблиц кроме основного ключа есть еще явные и неявные индексы, пусть всего порядка 4-х штук на таблицу. Итого, всего будет 4*4*4 возможных плана. Сверху этого учтём, что эти 3 таблицы именно так же соединяются в десятках других запросов, потому что это самые "ходовые" таблицы, например, описывающие движения чего-то там (взять обычную бухгалтерию, склад, или движения по банковским счетам). Итого, эти 4*4*4 плана могут быть частично или целиком переиспользованы м/у десятками запросов.

А значит, оценка плана для одного такого запроса может подходить для другого (мы же только что оценивали планы) и т.д.
Вплоть до того, что такую оценку и пересчёт индексов можно производить в фоне нон-стоп для самых "популярных" сценариев, т.е. де-факто вызываемых.

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

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


V>>По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.
IB>Советую ознакомиться с тем, как это работает в SQL БД последние лет тридцать.

Советую почитать букварь, начиная с буквы А. ))
Лишний раз демонстрировать неуклюжие замашки админов БД не стоило, ИМХО.

Здравствуйте, vdimas, Вы писали:
V>Слабовато с воображением.
Сочувствую.

V>А сколько всего может быть вариантов плана у среднего запроса?
V>Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
Это зависит от того, какую степень независимости клиента от сервера мы ожидаем.
То, что для клиента выглядит как простой select top * from ... на "той стороне" может превратиться в весьма разветвлённый запрос по нескольким физическим хранилищам и прочее.
И там вариантов плана будут десятки и сотни.
Но это не важно — даже если вариантов всего два, у клиента нет способа правильно выбрать тот из них, который эффективнее для конкретных параметров с конкретным наполнением данными.

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

V>И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
А, ну это отличная идея. Не факт, правда, что работоспособная.
Вот в качестве ближайшего примера — в моей конторе есть специальный сервер, куда каждая из инсталляций продукта сообщает статистику использования. Написан лет 10 назад, последние новости туда закоммитили году в 2012м, что ли.
"все запросы" там уже есть — штук пять веб-страничек, которые должны реализовывать все потребности клиентов.
Тем не менее, лично мои потребности эти прошитые запросы не удовлетворяют. Приходится писать скрипты, которые вытаскивают данные на клиента, и надругаются над ними уже локально.
Это показывает не то, насколько я крут в хтмл-скраппинге, а то, что все варианты запросов предусмотреть трудно.

V>По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.
Тут ключ к успеху — не нагрузка, а то, что все виды запросов, действительно, зафиксированы раз и навсегда. На бирже, я думаю, с 16 века мало что изменилось.
Поэтому можно себе позволить скомпилировать клиента вместе с сервером и забить на развитие.
И планы запросов можно прописать раз и навсегда. Роскошь, чё.
Увы — в этот класс приложений попадает очень мало всего. Тот же "банкинг" на самом деле устроен совсем не так, как во влажных мечтах С++ программистов. Там как раз SQL, адская Java, и прочие тормоза на ровном месте.
А чего вы хотели, когда реал-тайм банкинг — это выполнение перевода в течение 4х часов минимум (а SLA — вообще 2 банковских дня).
V>Иначе мы ведем разговор не о статике, а не понятно о какой химере, которую ты себе вообразил. ))
Ну вот теперь мы говорим о чём-то предметном — о приложениях, где объём функционала — с гулькин хрен, а стоимость потери времени — высока. То есть — о биржах.

V>Классный залёт.
V>"Это" становится известным в рантайм, а не компайл-тайм.
И слава байту. Иначе у нас первое же обновление сервера убьёт всех клиентов из-за несовместимости протокола.
V>Я дал все ключевые слова по которым можно выйти прямо на спеки некоторых бирж и там в доке найти ответы на все вопросы.
Ага. А также ещё на 100500 мусора, который не имеет отношения к теме разговора.
V>Наверно тем лучше, что в высокоскоростной сетке другого-то подхода и не используют.
Ну, то есть данных нет. Просто "ну, наверное там ребята разобрались". Можно было так и сказать, а не выделываться, намекая на какое-то сакральное знание, которым вы обладаете, а все остальные — неучи.

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

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

V>Или тупо забей, если накатила лень ума.
Это не лень ума, а разумный скепсис. Пока что он полностью подтверждается — внезапно оказывается, что предметом беседы стал не универсальный язык по доступу и манипуляции реляционными данными, а написание узкоспециализированных решений вроде бирж или телекоммуникаций. Ну вот в телекомах накат новых решений называется "развёртывание сетей нового поколения" и занимает годы. А убогий SQL в трёхзвенках позволяет выпускать обновления приложений еженедельно.

Нет, меня тоже лет 20 тому назад потрясло то, что за время, которое SQL Server тратит на выполнение одного запроса, локальное приложение "база телефонных номеров и адресов города Новосибирска" ухитряется поднять в память всю базу и найти ответ. Вот она — чудовищная сила статики! Код вместе со схемой данных, а схема — это прямое отображение атрибутов на смещения. В однопользовательском режиме, да ещё и при декомпрессии на лету — красота производительности. Угу. Однако все мы знаем, почему в многопользовательской среде клиппером пользоваться перестали, а перешли таки на MS SQL, Oracle, и прочие интербейзы.

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

V>Ограничений явного плана на такие вещи нет и быть не может.

Ну ты писал, что правило согласно которому нельзя класть логику в объекты на которые ORM мапит базу и согласно которому не надо использовать эти объекты в логике, что это правило проистекает из неудобств, которые решены в новых технологиях. А тут выходит, что правило всё равно актуально.

V>Это тебя не в ту сторону занесло.
V>Ты спросил о том, как "выглядит" технология для разработчика — я ответил.

Ну получается, что она от ORM слабо отличима и точно так же в объекты, которые мы вытаскиваем из базы — не надо класть логику.

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

S>Список нормальных ORM — в студию!

Я чего-то тут подумал. Hibernate получается. Вот как-то так. Остальные либо и вправду совсем плохие, либо я не знаком. Doctrine на php говорят тоже ничего, но я сам не щупал.

S>Вот именно. При этом мы понимаем, что помимо "таблиц" в RDBMS существенную роль играют view, table-valued functions, и прочий ad hoc.

Плюс типы данных "массив" и другие, отсутствующие в sql-92. Да, когда они нужны ORM мешает. Приходится либо их не использовать, либо ходить мимо ORM. Это боль.

S>Традиционные "full-blown" ORM из всего этого умеют готовить только таблицы и, немножко, view.

Hibernate ещё может хранимки и курсоры, но вообще да, тут не поспоришь.

S>Нет. И то и другое — штука вредная. Поясняю на пальцах: как только у вас появился lazy load, у вас появился кэш. Вместе с обязанностями по его поддержке в свежем состоянии.

lazy load вроде просто не лезет в базу за зависимыми сущностями, пока они не понадобятся. Это не кеш.

S>То есть если я скормил в базу хорошо структурированный запрос, типа "провести ордер" из теста TPC-C, у меня всё, что было lazy loaded, надо сразу отправлять на помойку, т.к. нет способа определить, какие из загруженных объектов устарели.

TPC-C — не ко мне.

S>Если у меня есть незакрытый unit of work, то я не имею права в этой же транзации пользоваться "запросом с каунтом", т.к. он увидит только то, что есть в RDBMS.

Ты имеешь в виду, что изменения, сделанные в текущем unit of work, будут заброшены в базу не раньше, чем мы его закроем? Хочется сказать — не делай так. Но вообще аргумент, наверное в кассу. Если о чём-то надо помнить — это не очень хорошо.

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

V>>Когда данные из разогретой базы достаются прямиком из оперативки (а таких будет 99.99% случаев в тех самых нагруженных сценариях), то они достаются за единицы/десятки микросекунд.
S>Да-да, я помню. И данных про то, сколько занимает разбор запроса и формирование ответа как не было так и нет.

Вдогонку, набрёл на устаревшие данные (2013-й год):

Approximately 25 billion messages pass through NASDAQ OMX's U.S. equities and options systems on an active day, which amounts to over 1 million transactions per second in a trading day. During volatile periods, peak message traffic can be double.

Мои дополнения:

* По наблюдаемым мною ситуациям на бирже, колебания отличаются от среднего дневного трафика значительно больше, чем в два раза — до 4-5-ти раз аж бегом;

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

Например, если ты решил продать/купить ценные бумаги только одного вида, то тебе надо совершить порядка 10-15 запросов в базу ради одной сделки (транзакции).

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

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

Далее.

Обычные SQL-сервера тоже используются на биржах.
Но как они используются? — как хранилища "подробностей" и как хранилище данных для последующей неспешной статистической обработки.

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

Есть еще скидывание логов транзакций — т.е. отдельная группа серверов занимается только тем, что с некоторым отставанием пишет происходящее на бирже в "обычную" базу. Так-то данные в любом случае живут и изменяются в транзакционной манере в специализированной БД биржи, т.е. такое копирование происходит сугубо из-за прикладных соображений, чтобы "поделиться информацией с миром SQL", т.е. потом из SQL-базы происходит неспешная раздача инфы (в том числе аггрегированной) через web-интерфейсы, OLAP и прочие неторопливые плюшки, для которых гибкость имеющегося на прямо сейчас инструментария важнее торопливости.

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

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

V>>А сколько всего может быть вариантов плана у среднего запроса?
V>>Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
S>Это зависит от того, какую степень независимости клиента от сервера мы ожидаем.

Вот, кстате, первая разумная мысль.
Одобряю.


S>И там вариантов плана будут десятки и сотни.

От единиц до десятков, потому что "по нескольким физическим хранилищам и прочее" уже известно на момент компиляции, заведомо плохие ветки отсекаются так же, как они эффективно отсекаются в рантайм у современных SQL баз. С той лишь разницей, что предварительную оценку по заведомо плохим вариантам уже делать не надо в рантайм.

Т.е., поменял конфигурацию базы — всё перекомпиллировалось.
Как-то так.
Примерно как в 1C, я же приводил уже пример.
И да, для клиента АПИ мог не поменяться, т.е. некоторая изоляция "интерфейса" от "релизации" имеет место быть, как и в любой сложной системе.


S>Я не вижу связи между "во вполне конкретной конструкции join" и "суммой всех вариантов по всем запросам".

Это из опыта написания складских и учётных систем и виденных многих.
Связи м/у таблицами отвечают предметной области, эти связи участвуют идентичным образом во многих запросах, где встречаются одни и те же таблицы.


S>В самых простых учётных системах есть крайне популярная штука — star join.

Дело не в простоте учётной системе, а в требованиях некоей аналитики.

Потому что, когда речь идёт о движениях, то никаких "star" быть не может по причине ограничений целостности данных.
(кстате, частично эти ограничения целостности можно тоже отслеживать в compile-time)

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

V>>И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
S>А, ну это отличная идея. Не факт, правда, что работоспособная.

Крупные ERP-системы не в курсе, что не факт, что работоспособная.


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

А в той же 1С или Парусе или Axapta ты дорабатываешь саму "систему" и вот требуемый запрос для нового требуемого отчёта волшебным образом "возникает". Как и везде в этой области, собсно.


S>Тут ключ к успеху — не нагрузка, а то, что все виды запросов, действительно, зафиксированы раз и навсегда.

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

Например, движения по счетам в бухгалтерии — это ровно одна основная таблица.
Движения товаров при средневзвешенном их учёте — тоже ровно одна "двигающаяся" таблица.
При партионном учёте — всего две "двигающихся" — партии и расход.

Остальные данные имеют характер справочных.

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

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


S>Тот же "банкинг" на самом деле устроен совсем не так, как во влажных мечтах С++ программистов. Там как раз SQL, адская Java, и прочие тормоза на ровном месте.

Банкинг устроен слишком по-разному.
Настолько слишком, что вряд ли ты в состоянии представить себе всю палитру используемых решений.
Фактически, учётная система каждого крупного банка — это его и ноу-хау и субъект конкуренции.
Я лишь упоминал случаи, когда некоторые крупные банки (типа дойчбанка) тоже используют подходы к опердню, как в биржах.
И я уверен, что в своё время они замечательно прошли все стадии "адской джавы и SQL".

В принципе, уже для данных вчерашнего дня джава + SQL смотрятся великолепно! ))
И её там для таких именно целей в избытке.
Для всех обслуживающих утилит — тоже.


S>А чего вы хотели, когда реал-тайм банкинг — это выполнение перевода в течение 4х часов минимум

4 часа происходит не сам перевод.
Это девочка оператор должна проверить твою виртуальную платёжку и дать ей ход.
Если это перевод м/у странами, то будет еще один клерк, который проверит операцию и даст ей ход дальше.
На приёмной стороне аналогично.
Совсем другое дело перевод внутри одной страны м/у банками, как это работало (просто я немного в курсе) для украинской платёжной системы.
Не успеет оператор отправить — уже приходит смс о получении.


S>Ну вот теперь мы говорим о чём-то предметном — о приложениях, где объём функционала — с гулькин хрен, а стоимость потери времени — высока. То есть — о биржах.

Дык, я сразу давал предметную область: биржи, банки, опердни, сотовая связь, интернет-роутинг в крупных узлах и т.д.
Там тоже надо "как-то это всё писать".


V>>"Это" становится известным в рантайм, а не компайл-тайм.
S>И слава байту. Иначе у нас первое же обновление сервера убьёт всех клиентов из-за несовместимости протокола.

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

V>>Я дал все ключевые слова по которым можно выйти прямо на спеки некоторых бирж и там в доке найти ответы на все вопросы.
S>Ага. А также ещё на 100500 мусора, который не имеет отношения к теме разговора.

Это тебе так кажется. "OMnet/OMX" — вполне себе URL при наличии доступа к гуглу.


S>Ну, то есть данных нет. Просто "ну, наверное там ребята разобрались". Можно было так и сказать, а не выделываться, намекая на какое-то сакральное знание, которым вы обладаете, а все остальные — неучи.

Ничего не понял — в чём сакральность, эй?
Я приводил вполне конкретные цифры roundtrip-а.
От аналогичных на SQL-серваке на той же машине они отличаются на порядок или больше.

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

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

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


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

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

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

Это насчёт уместности джавы или дотнета в таких делах.


S>для биржи не грех и кастомное решение навелосипедить,

А еще не грех взять движок от DB2, убрав из него всё, что касается обработки конкретно SQL, оставив только механику и надёжность. ))

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


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

Не оказывается ни разу. ))

1. Эти области были приведены лишь как пример, где от SQL ПРИШЛОСЬ отказаться;
И такие области тоже надо уметь окучивать.
А "разрывы" в технологиях всегда болезненны и являются лишним источником ошибок.

2. Статика не отменяет динамику, а замечательно её дополняет.
Даже в С++ часто используют динамику в полный рост. Т.е. не dynamic_cast, а именно некие фреймворки, позволяющие оперировать динамическими данными. Как пример, хосподя, весь COM, OLE VARIANT и т.д.

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

Поэтому, все мои исходные тезисы в силе:
— убрать разрыв технологий;
— дать эффективный в рантайм инструмент;
— повысить контроль целостности и типизации данных еще на этапе разработки.

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

V>>Ограничений явного плана на такие вещи нет и быть не может.
T>Ну ты писал, что правило согласно которому нельзя класть логику в объекты на которые ORM мапит базу и согласно которому не надо использовать эти объекты в логике, что это правило проистекает из неудобств, которые решены в новых технологиях. А тут выходит, что правило всё равно актуально.

Не выходит, это ты только что так сам решил.
Кто это может мне запретить оперировать непосредственно "протокольными" типами данных? ))

Хотя, справедливости ради, у себя в С++ мы их заворачиваем в удобные обертки для доступа и манипулирования содержимым.
Просто в С++ любые инлайные обертки добавляют ровно ноль косвености, т.е. абсолютно бесплатны.


V>>Это тебя не в ту сторону занесло.
V>>Ты спросил о том, как "выглядит" технология для разработчика — я ответил.
T>Ну получается, что она от ORM слабо отличима и точно так же в объекты, которые мы вытаскиваем из базы — не надо класть логику.

А как много логики ты кладёшь в аргументы и возвращаемые результаты ф-ий?
Наверно, логики кладёшь не много, но используешь эти типы данных в логике широко.
Как-то так.

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

T>Hibernate ещё может хранимки и курсоры, но вообще да, тут не поспоришь.
Ну, дело не в курсорах. Дело в ad hoc запросах, для которых нет готового типа данных в нашей OO-модели.
Классика жанра — есть студент, ок class Student. Есть учебный курс — ок, есть class Course.
Есть оценка за курс — хм, куда мы её поместим? Ну ок, пусть у нас будет дочерняя коллекция у студента — Student.CourseMarks, состоящая из class CourseMark{Course Cource, int Mark}.
Нам надо построить отчёт "студент — средняя оценка по всем курсам". Какого класса будет элемент этого списка?

T>lazy load вроде просто не лезет в базу за зависимыми сущностями, пока они не понадобятся. Это не кеш.
И где же лежат зависимые сущности, которые "понадобились"?

T>TPC-C — не ко мне.
Ну из любой учётной системы. Вкратце, там мы бежим по строчкам ордера, и для каждой из них уменьшаем остаток товара на складе на соответствуюшее количество. Если натыкаемся на недостаток — то откатываем всю транзакцию. Если всё нашлось — то помечаем ордер как "ожидает отгрузки".
В SQL это всё делается одним стейтментом. В ORM — это 2*N запросов на чтение и N на модификацию. И это я ещё не говорю про false fails, когда мы обламываемся при записи из-за optimistic locking failure. Тогда нам снова приходится делать всю волынку сначала.

T>Ты имеешь в виду, что изменения, сделанные в текущем unit of work, будут заброшены в базу не раньше, чем мы его закроем? Хочется сказать — не делай так. Но вообще аргумент, наверное в кассу. Если о чём-то надо помнить — это не очень хорошо.
Дело не в том, чтобы "помнить". Дело в том, что нам же запросы нужны не сами по себе, а для выполнения бизнес-логики. В том числе и во время транзакции. Получается, что мы не можем пользоваться "прямым SQL" минуя кэш лейзи-лоада внутри транзакции, что как раз заставляет нас писать вот этот вот ужасный код с foreach(orderline in order.lines)

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



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

V>Например, если ты решил продать/купить ценные бумаги только одного вида, то тебе надо совершить порядка 10-15 запросов в базу ради одной сделки (транзакции).

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

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

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

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

V>Пипец...
V>

Да чушь ты несешь только так.

MTD>>Кстати, ты слился с вопросом про производительность БД, а я так ждал.

V>Я тебе уже отвечал — единицы/десятки микросекунд на ответ.

Не понял.

V>В итоге — готовность работать с современными гигабитными сетками.
V>Мейнстримовые БД с такими сетками работать де-факто не готовы.

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

Так они справляются или нет?

V>В типизациях плаваешь, про современные БД не в курсе.

Так в лужу сесть надо постараться, а ведь очень легко узнать где я работаю

V>>>Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
MTD>>Где? Когда С++ принимает пакет по сети? Ну да, а что делать?

V>Мне действительно не интересно рассказывать, как в С++ можно принимать пакеты по сети без всякой динамической типизации.

И снова слился.

V>Я не надуваю щёки, коллега, просто это отдельная тема, оффтоп.

Да вот прям сейчас это делаешь.

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

V>Да. Зло и нубство а-ля BASIC из середины 70-х годов.

Обоснуй.

V>Современные эффективные системы уже давным давно давно так не пишутся.

Как они пишутся?

V>Потому что уже относительно давно размеры оперативки позволяют немного раздуть код ради исключения лишних телодвижений в рантайме.
V>Согласись, что лишние 3-5 мег бинарного кода (после оптимизации) в пересчёте на сервак сегодня никто не заметит.

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

MTD>>В смысле взять структуру и ее бинарное представление сохранить, а потом прочесть и скастить? Не знаешь, почему это плохая идея?

V>Ну ты же так делаешь с оперативной памятью?

Кроссплатформенный код ты видно тоже не писал. И это не единственная проблема с данным подходом в контексте обсуждения.

V>Я тебе больше скажу — даже когда по сети гоняются данные с динамической типизацией — то сама-то метаинформация над этой динамической типизацией, она ведь строго типизированная!

И к чему ты это сказал?

V>>>Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
MTD>>То есть про БД ты ничего не знаешь, но мнение имеешь?

V>Это попахивает тем твоим советом "почитать про хранимые процедуры".
V>Коллега, ты реально с другой стороны Луны. От современного IT малость далёк.

Ага, ага. Полегчало?

V>>>Твои вопросы не относятся к сути моих предложений от слова никак. ))
MTD>>Просто они для тебя неудобные, а как взрослый человек поступить ты не в силах.

V>Почему?

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

V>Я как раз запросто, тот еще любитель называть вещи своими именами.
V>Просто конкретно в нашей ситуации если, то меня сходу забанят. ))

Это ты сейчас снова соврал? Собственно, что еще от такого ожидать? Все, что нужно про тебя знать здесь: http://rsdn.org/forum/flame.comp/6949966.1

Автор: MTD
Дата: 31.10.17

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

S>Отож. Вот то ли дело тупой SQL. Там, помнится, всего-то полмиллиона транзакций в секунду.
Для полумилииона транзакций в SQL нужны очень специальные условия. То есть, минимум join'ов (если вообще), sharding таблиц по какому-то признаку или небольшой объём данных (чтоб всё в памяти было). При этом оно будет в любом случае с кластером и облаком админов для шаманства вокруг него.

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

S>Нам надо построить отчёт "студент — средняя оценка по всем курсам". Какого класса будет элемент этого списка?

Ну, какого надо, такого и будет. Предлагаю StudentAverage{Student student, Integer avg}

T>>lazy load вроде просто не лезет в базу за зависимыми сущностями, пока они не понадобятся. Это не кеш.
S>И где же лежат зависимые сущности, которые "понадобились"?

В памяти приложения. Если ты сделаешь не lazy load, они тоже будут лежать в памяти приложения. lazy load тут ничего не меняет.

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

Это ты о том, что можно сделать один sql запрос, который все операции проведёт не выходя за пределы СУБД, а можно слать несколько отдельных запросов из приложения? И, так как ORM не поддерживает ничего, кроме базового sql — с помощью ORM такого сделать нельзя? Согласен — нельзя, согласен — недостаток, это тот случай, когда надо использовать хранимки.

S>Получается, что мы не можем пользоваться "прямым SQL" минуя кэш лейзи-лоада внутри транзакции, что как раз заставляет нас писать вот этот вот ужасный код с foreach(orderline in order.lines)

Мне кажется мы как-то по разному используем термин lazy load. Вот смотри, допустим, мы вытащили запросом студентов из первого пункта. Плюс мы знаем, что CourseMark загружаются лениво. Мы у половины студентов посмотрели оценки за курсы, а у половины — нет. Теперь у нас у половины студентов CourseMark есть в памяти приложения, а у половины — нет. А дальше мы отсылаем запрос с каунтом по всем студентам. Запрос пойдёт мимо приложения, сразу в БД. Подсчитает результат и вернёт его нам. То, что по факту у половины студентов CourseMark не загружен ни на что не повлияет.

А вот, если ты напишешь код типа

foreach(student in students) { 
    foreach (course in student.courseMarks){
        sum += course.mark; 
    } 
}

то нарвёшься на проблему N + 1. Из-за lazy load.

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

V>Не выходит, это ты только что так сам решил.
V>Кто это может мне запретить оперировать непосредственно "протокольными" типами данных? ))

Запретить тебе мало что можно. Можно даже написать весь код не используя структур и внутри main. Но так не делают. То же самое с использованием объектов, которые получаются из базы. Только речь не о протокольных типах данных, а об отображении таблиц БД на структуры. Почему логику туда не надо класть я уже писал, думаю, ты со мной согласен.

А насчёт использования в приложении — если ты это делашь — ты завязываешь бизнес логику на логику хранения данных, а это нехорошо.

V>Хотя, справедливости ради, у себя в С++ мы их заворачиваем в удобные обертки для доступа и манипулирования содержимым.

Можно кусок кода? Я лучше пойму, что ты имеешь в виду.

V>А как много логики ты кладёшь в аргументы и возвращаемые результаты ф-ий?
V>Наверно, логики кладёшь не много, но используешь эти типы данных в логике широко.

Логики немного, да, и использовать эти данные в логике не очень правильно. Но я тут хочу вернуться к тому, что штука, про которую ты говоришь — ORM и есть.

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

V>>Пипец...
V>>
MTD>Да чушь ты несешь только так.

Не, чушь вот она:

С++ тоже динамически типизирован? Он же читает байты из сокета или файла, например.

Мусор в голове — мусор в словах.


MTD>>>Кстати, ты слился с вопросом про производительность БД, а я так ждал.
V>>Я тебе уже отвечал — единицы/десятки микросекунд на ответ.
MTD>Не понял.

Цикл вопрос-ответ — единицы десятки микросекунд.


MTD>А все эти петабайты данных из астрала что-ли берутся?

Я уже на этот ТУПЕЙШИЙ вопрос отвечал.


MTD>Так в лужу сесть надо постараться, а ведь очень легко узнать где я работаю

Ты не работаешь, ты динамишь работодателя.
Из твоего кода:

boost::thread(boost::bind(&Worker::ThreadFunction, this)))

Когда достаточно такого:

boost::thread(&Worker::ThreadFunction, this))

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

В деструкторе у тебя вызов:

Shutdown_ = true;
...
Condition_.notify_one();

В то время как в потоковой процедуре ожидается:

Condition_.wait(lock);

И затем заход на новый цикл с проверкой на существование ровно одной задачи в очереди. ))

Итого, неопределённое поведение.
Если было необходимо выполнить все задачи из очереди перед выходом из потоковой процедуры, то эта логика не реализована.
Если необходимо было отреагировать на Shutdown_ = true и немедленно прекратить выполнять задачи — эта логика тоже не реализована.
Твой код работает на какую сторону с утра встанет, как грится.

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

Про автоматы тоже каша, не указано, что модель Мура и что схема синхронная и т.д.
Еще учит...


V>>>>Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
MTD>>>Где? Когда С++ принимает пакет по сети? Ну да, а что делать?

V>>Мне действительно не интересно рассказывать, как в С++ можно принимать пакеты по сети без всякой динамической типизации.
MTD>И снова слился.

Врать изволишь.
Тебе никто не обещал ликбеза по отличиям динамической типизации от статической.
Просто тебе вдруг ЗАХОТЕЛОСЬ такого ликбеза и ты был справедливо неявно послан, с такими странными "желаниями".


MTD>Да вот прям сейчас это делаешь.

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


MTD>Кроссплатформенный код ты видно тоже не писал. И это не единственная проблема с данным подходом в контексте обсуждения.

В шоке, реально.

Ты чем больше открываешь рот, тем больше подставляешься.
У тебя уже в кроссплатформенности проблема.
Потом пойдут проблемы с порядком MSB/LSB.
Потом про разрядность данных вспомнишь.

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

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

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

S>>Отож. Вот то ли дело тупой SQL. Там, помнится, всего-то полмиллиона транзакций в секунду.
C>Для полумилииона транзакций в SQL нужны очень специальные условия. То есть, минимум join'ов (если вообще), sharding таблиц по какому-то признаку или небольшой объём данных (чтоб всё в памяти было). При этом оно будет в любом случае с кластером и облаком админов для шаманства вокруг него.
Это мировой рекорд в TPC-C. Там количество joinов и объём данных регламентированы условиями теста. И транзакции запрещено "коммитить" в памяти.

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

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

Учу читать:

over 1 million transactions per second

V>>Ты уже прикинул производительность подсистемы хранения и обработки данных?
V>>Причём, работающей в транзакционном режиме.
S>Отож. Вот то ли дело тупой SQL. Там, помнится, всего-то полмиллиона транзакций в секунду.

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

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

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

В общем, даже не смешно.
Скажи — а какой смысл вообще разгребать такой трафик глупого SQL на ровном месте и каждый божий раз как с 0-ля разбираться с каждым из миллиарда типовых запросов?
Вот смысл, ы?
За что именно ты сейчас борешься? ))


S>Правда, там в одну транзакцию вовлечено немножко больше, чем регистрация сделки на одну бумагу на бирже. Ну, это несущественно.

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


S>Ну, то есть осетра придётся таки урезать.

Не придётся.


S>И что от "SQL безнадёжно устарел" мы переходим

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


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

Преимущество его сейчас в его распространённости.
У Фортрана тоже было ровно такое же преимущество одно время. ))
Отсюда твои спекуляции (а ты не можешь не спекулировать, вестимо) не на кол-ве задач, действительно требующих динамику, характерную для SQL, а на на людях, "кому он нужен и кому не нужен". Бррр.. сплошная нечестность в спорах...


S>(Сколько у нас бирж в мире?)

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

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

Ведь хорошее железо и хорошая сетка уже давно есть.
А вот головы и рук — нет.
Но некоторым коллегам, смотрю, от этого даже не стыдно. ))

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

T>Ну, какого надо, такого и будет. Предлагаю StudentAverage{Student student, Integer avg}
То есть мы обязаны изобретать целый отдельный класс на каждый результат проекции/группировки. Это как бы тупик.
В Linq для этого есть анонимные типы.

T>В памяти приложения. Если ты сделаешь не lazy load, они тоже будут лежать в памяти приложения. lazy load тут ничего не меняет.
Это и есть кэш — потому, что повторное обращение к "сущности", которая понадобилась ещё раз, обязано вернуть тот же экземпляр. Иначе будет совсем плохо.

T>Это ты о том, что можно сделать один sql запрос, который все операции проведёт не выходя за пределы СУБД, а можно слать несколько отдельных запросов из приложения? И, так как ORM не поддерживает ничего, кроме базового sql — с помощью ORM такого сделать нельзя?
Обычные ORM вообще ничего не поддерживают. Там каждая модификация — это отдельное update student set lastname = ? where id = ?.
T>Мне кажется мы как-то по разному используем термин lazy load. Вот смотри, допустим, мы вытащили запросом студентов из первого пункта. Плюс мы знаем, что CourseMark загружаются лениво. Мы у половины студентов посмотрели оценки за курсы, а у половины — нет. Теперь у нас у половины студентов CourseMark есть в памяти приложения, а у половины — нет. А дальше мы отсылаем запрос с каунтом по всем студентам. Запрос пойдёт мимо приложения, сразу в БД. Подсчитает результат и вернёт его нам. То, что по факту у половины студентов CourseMark не загружен ни на что не повлияет.
Ну, во-первых, это уже повлияло на то, что у нас вместо одного запроса, который бы всосал студентов вместе с оценками, уехало N+1 запросов. Что сразу же уронило производительность примерно в N раз.
Во-вторых, нам просто повезло на синтетической задаче — нам не потребовалось ничего изменять, т.к. оценки студентов уже известны. А вот если бы мы должны были заниматься чем-то типа комплектования заказа, каждый раз выбирая склад с максимальными остатками для каждого товара, то у нас после первой же модификции, проведённой в памяти, результаты "запроса из базы" станут нерелевантными. И придётся по честному протаскивать все вот эти вот остатки на складах через тот же lazy-load кэш.

T>А вот, если ты напишешь код типа

T>

T>foreach(student in students) { 
T>    foreach (course in student.courseMarks){
T>        sum += course.mark; 
T>    } 
T>}
T>

T>то нарвёшься на проблему N + 1. Из-за lazy load.
Надо понимать, что именно такой код не пишут почти никогда. Мы ж программисты — мы делаем Инкапсуляцию! Нужно среднее — добавляем студенту вычисляемое свойство AverageMark, с геттером, который бежит по коллекции StudentMarks.
И биндим к гую вот эту вот коллекцию студентов, где в колонке 1 будет LastName, а в колонке 2 — AverageMark.
Всё красиво, абстрактно, гибко, тестируемо и пр. Вот только под капотом у нас N+1, который с первого взгляда и не увидишь. Leaky, мать её, abstraction.
А использование прямого SQL — это как раз отказ от всей инкапсуляции.
В SQL Server я могу определить view, в котором будет вычисляемое поле AverageMark. И оно будет извлекаться за 1 стейтмент; при этом если я делаю запрос к этому view, в котором проекция отрезает AverageMark, то оптимизатор даже лезть в табличку StudentMarks не будет. Не будет ни Join, ни Aggregate.
Это — роскошь, недоступная традиционным ORM. Вот к чему надо стремиться.
в Linq изобразить что-то подобное довольно-таки тяжело, но можно. Ну, то есть можно сварганить прямой аналог — IQueryable<T> StudentsWithMarks. Но это не так красиво и ООПшно, как возможность объявить вычисляемое свойство прямо на студенте.

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

V>Альтернативные варианты порождаются альтернативными явными индексами или неявными, когда данные по природе своей "упорядочены", как, например, если в условиях запроса фигурируют даты.

Это единственное что, по твоему мнению, может варьироваться в планах?

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

Не зависит. Планировщик не оперирует с данными, он оперирует со статистикой, а ее объем вполне конечен.

V> и текущего состояния пересчитанных индексов (их актуальности).

Индексы в РСУБД всегда актуальны.

V>Фишка в том, что всевозможные скомпиллированные планы запросов уже могут быть.

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

V>>>По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.
IB>>Советую ознакомиться с тем, как это работает в SQL БД последние лет тридцать.
V>Советую почитать букварь, начиная с буквы А. ))
V>Лишний раз демонстрировать неуклюжие замашки админов БД не стоило, ИМХО.

Писец ты наглый.

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

V>Не, чушь вот она:
V>

V>С++ тоже динамически типизирован? Он же читает байты из сокета или файла, например.

V>Мусор в голове — мусор в словах.

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

MTD>>>>Кстати, ты слился с вопросом про производительность БД, а я так ждал.
V>>>Я тебе уже отвечал — единицы/десятки микросекунд на ответ.
MTD>>Не понял.

V>Цикл вопрос-ответ — единицы десятки микросекунд.

MTD>>А все эти петабайты данных из астрала что-ли берутся?

V>Я уже на этот ТУПЕЙШИЙ вопрос отвечал.

Где? Вопрос не тупой, вот на что он был задан:

V>В итоге — готовность работать с современными гигабитными сетками.
V>Мейнстримовые БД с такими сетками работать де-факто не готовы.

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

Как ты юлишь и выкручиваешься как щенок нашкодивший доставляет.

V>Ты не работаешь, ты динамишь работодателя.

Ну так то работодателю видней, а не ноунейму из провинции.

V>Из твоего кода:

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

V>И так у тебя везде.

Где?

V>Поверхностен, не вникаешь в предмет, не включаешь моск во время работы.

Значит мне и невключенного мозга хватает, чтобы таких как ты обходить.

V>В деструкторе у тебя вызов:
V>И затем заход на новый цикл с проверкой на существование ровно одной задачи в очереди. ))

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

V>Итого, неопределённое поведение.

Обоснуй.

V>Про таких коллег говорят "разбрасывает коровьи лепешки в коде".

Да, код реально плох.

V>Про автоматы тоже каша, не указано, что модель Мура и что схема синхронная и т.д.

Нельзя в одной статье объять все.

V>Еще учит...

И люди благодарны, а ты только лепешки подкладывать на форуме мастер

V>>>>>Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
MTD>>>>Где? Когда С++ принимает пакет по сети? Ну да, а что делать?

V>>>Мне действительно не интересно рассказывать, как в С++ можно принимать пакеты по сети без всякой динамической типизации.
MTD>>И снова слился.

V>Врать изволишь.

Нет, ты сливаться изволил. Где вранье? Ты отказался комментировать, что это как не слив?

V>Тебе никто не обещал ликбеза по отличиям динамической типизации от статической.
V>Просто тебе вдруг ЗАХОТЕЛОСЬ такого ликбеза и ты был справедливо неявно послан, с такими странными "желаниями".

Может и захотелось, может я ничего не знаю — это не отменяет того, что ты пустослов и слился.

V>ОК, виноват, надо было послать сходу, чтобы вернуть тебя на грешную землю.

Подгорает у тебя знатно. Погонял я тебя от души.

V>А так, смотрю, дай наглецу палец — откусит по локоть...

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

MTD>>Кроссплатформенный код ты видно тоже не писал. И это не единственная проблема с данным подходом в контексте обсуждения.

V>В шоке, реально.

Учись, еще не поздно.

V>Ты чем больше открываешь рот, тем больше подставляешься.

Правда, лучше бы ты помалкивал.

V>У тебя уже в кроссплатформенности проблема.

У меня все ок, у тебя проблема.

V>Это ж до какой степени надо считать всех вокруг идиотами, чтобы нести подобную хрень?

Вопрос ты себе задал правильный. Подумай.

V>Вернее, это ж насколько надо быть слепым, чтобы считать всех вокруг идиотами.

Вопрос ты себе задал правильный. Подумай.

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

Я тебя вообще не знаю. А то еще непонятно в чью пользу будет сравнение.

Ну и все что нужно про тебя знать, здесь: http://rsdn.org/forum/flame.comp/6949966.1

Автор: MTD
Дата: 31.10.17

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

T>Много раз слышал от разных людей.

А я вот про рептилоидов с Нибиру много раз от разных людей. Иллюстрация понятна?

T> Для начала пара слов про производительность. С производительностью проблема возникает от того, что ORM тупо не поддерживают плюхи конкретных СУБД.

Давай конкретно — что это за плюхи и почему ОРМ не может их использовать?

T>так как ORM упрощает 80% типовых операций и делает это хорошо.

Хороший ОРМ упрощает 99% всех операций.

T>По идее ORM занимается построением типовых запросов и отображением таблиц в объекты, в которых логики быть РЕШИТЕЛЬНО НЕ ДОЛЖНО.

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