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

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

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

V>Учу читать:
V>

V>over 1 million transactions per second

facepalm. Сначала сам научись читать. Сопоставлять приведённые цифры. Вот, скажем, сколько сообщений в секунду они обрабатывают?
В среднем — 1.7 миллиона. Я так полагаю, что это и есть те самые "over 1 million transactions", потому что иначе окажется, что транзакция в среднем соответствует 1.2-1.5 сообщениям,
Пиковая нагрузка — вдвое выше. Это по официальным данным, а не высосанным из пальца.
Ок, Nasdaq молодцы, могут до примерно 2х с копейками миллионов транзакций в секунду.

V>Т.е. всё еще на примерно пару порядков меньше требуемого, с учётом колебаний нагрузки и трафика запросов, резко превышающего трафик транзакций? ))
Как видим. не так уж и резко.
V>Твой MS SQL умеет делать полмиллиона добавлений одной строчки в одну таблицу в самой зверской конфигурации, разве что.
V>Но уже полмиллиона средних по тяжести запросов — не умеет.
Да, увы, MS SQL — не лидер. Лидер — Oracle. Они делают 30 миллионов транзакций в минуту.
V>В случае биржи нужно в рамках одной транзакции обновить данные в двух таблицах и добавить строчку/строчки в еще две.
V>И при этом выполнять агрегацию на регистрах и одновременно выполнять в несколько раз больше запросов на чтение, чем транзакций.
Да, TPC-Cшные транзакции тоже засчитывают только модификации. Одновременно с которыми нужно выполнять в несколько раз больше запросов на чтение. Подробности можно прочитать здесь: http://www.tpc.org/TPC_Documents_Current_Versions/pdf/tpc-c_v5.11.0.pdf, раздел 2.

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


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

V>Преимущество его сейчас в его распространённости.
Преимущество — в существенной независимости клиента от сервера. В типичной ентерпрайз системе образца 90х-2000х — пара тысяч хранимых процедур. Каждая — для какого-то сценария. Не три типа "заранее известных" запросов, а две тысячи! Заниматься их ручной оптимизацией в компайл-тайме — безумие.
V>А когда вообще люди начнут отвыкать от того, что "база данных всегда тормозит" и вздохнут спокойно?
Когда появятся нормальные приложения. База данных обычно летает как трофейный мессершмит, если не навешивать над ней убогие ORM-системы.
Когда мне тут рассказывают, что миллион строк — это бигдата, я смеюсь. Запросы по миллиону строк отлично отрабатывает мой ноутбук, при работе от батарейки.

V>Ведь всех бесит, что "интернет всегда тормозит", а тормозит он во многом, тоже из-за баз данных, бо статические страницы залетают быстро.
База данных как раз это не самое узкое звено. Просто в 2000х оказалось, что разработчиков нужно много, а изучать SQL у них времени нету. Если в базу лазить построчно, как делают 95% ORM инструментов, то можно убить любую производительность.
А главная мысль тут — в том, что отказ от SQL сам по себе ничего не даст. Приложения тормозят не потому, что парсинг SQL или TDS дорого стоит, а потому, что на 1 веб-страницу делается 150 запросов к базе. Тупо стоимость сетевого раундтрипа съедает все ресурсы. Уберём мы эти пикосекунды парсинга — ну так проблема (N+1) * (M+1) никуда не денется. Это же прикладной код так написан, что не даёт движку оптимизировать запрос.
Я бы копал в сторону декларативного определения viewModel в коде так, чтобы все данные поднимались за 1 обращение к СУБД. А механизмы экономии на парсинге и построении плана уже известны — понятие "prepared statement" существует во всех ведущих СУБД уже лет 30 как.

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

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

почему не должно?

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

S>Преимущество — в существенной независимости клиента от сервера. В типичной ентерпрайз системе образца 90х-2000х — пара тысяч хранимых процедур.

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

S>Когда мне тут рассказывают, что миллион строк — это бигдата, я смеюсь. Запросы по миллиону строк отлично отрабатывает мой ноутбук, при работе от батарейки.

+1. Вообще, помнится, трехзвенка с сиквелом на одном дохлом целероне со скромным объемом памяти строила на миллионе строк шахматку меньше минуты. Без каких либо кубов и их имитации, тупо по сырым данным.

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

S>То есть мы обязаны изобретать целый отдельный класс на каждый результат проекции/группировки. Это как бы тупик.
S>В Linq для этого есть анонимные типы.

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

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

Это и есть кеш, да. Но сущности попадут в кеш независимо от того, как их загрузили — lazy или eager. Поэтому проблема возникает не из-за lazy load.

S>Обычные ORM вообще ничего не поддерживают. Там каждая модификация — это отдельное update student set lastname = ? where id = ?.

Ну я говорю ORM и имею в виду в первую очередь Hibernate. Так это не единственная альтернатива. А что ты имеешь в виду? Какие ORM?

S>Ну, во-первых, это уже повлияло на то, что у нас вместо одного запроса, который бы всосал студентов вместе с оценками, уехало N+1 запросов. Что сразу же уронило производительность примерно в N раз.

Да, повлияло, да уронило, да это проблема lazy load, но не та, про которую ты вначале говорил. Когда заранее знаешь, что lazy load мешает — надо включить eager.


T>>то нарвёшься на проблему N + 1. Из-за lazy load.
S>Надо понимать, что именно такой код не пишут почти никогда. Мы ж программисты — мы делаем Инкапсуляцию! Нужно среднее — добавляем студенту вычисляемое свойство AverageMark, с геттером, который бежит по коллекции StudentMarks.
S>И биндим к гую вот эту вот коллекцию студентов, где в колонке 1 будет LastName, а в колонке 2 — AverageMark.

Я несколько раз написал, что так делать нельзя, когда используешь ORM. Увы.

S>Всё красиво, абстрактно, гибко, тестируемо и пр. Вот только под капотом у нас N+1, который с первого взгляда и не увидишь. Leaky, мать её, abstraction.

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

S>А использование прямого SQL — это как раз отказ от всей инкапсуляции.
S>В SQL Server я могу определить view, в котором будет вычисляемое поле AverageMark. И оно будет извлекаться за 1 стейтмент; при этом если я делаю запрос к этому view, в котором проекция отрезает AverageMark, то оптимизатор даже лезть в табличку StudentMarks не будет. Не будет ни Join, ни Aggregate.
S>Это — роскошь, недоступная традиционным ORM. Вот к чему надо стремиться.

Вот этот view ты замапишь на сущность в коде и будешь спокойно использовать.

S>в Linq изобразить что-то подобное довольно-таки тяжело, но можно. Ну, то есть можно сварганить прямой аналог — IQueryable<T> StudentsWithMarks. Но это не так красиво и ООПшно, как возможность объявить вычисляемое свойство прямо на студенте.

Не красиво и не ООПшно, но на то он и ORM. Я считаю, что пока хороших инструментов нет, лучше не прятать базу далеко, во избежание.

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

S>Когда мне тут рассказывают, что миллион строк — это бигдата, я смеюсь. Запросы по миллиону строк отлично отрабатывает мой ноутбук, при работе от батарейки.
Угу. Недавно оптимизировал результат работы подобных разработчиков. Их код работал 9 дней на нескольких миллионах строк. Прописью — девять дней.
Полдня работы по переписыванию с С# рибара на SQL — время работы сократилось до 5 минут. Плюс пара новых индексов — время работы сократилось до 30
секунд. Т.к. это часть ночного пакета, дальше оптимизировать смысла не имеет, оставил так.

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

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

_AB>Угу. Недавно оптимизировал результат работы подобных разработчиков. Их код работал 9 дней на нескольких миллионах строк. Прописью — девять дней.
_AB>Полдня работы по переписыванию с С# рибара на SQL — время работы сократилось до 5 минут.

А у меня наоборот было как-то. Была выгрузка из БД, которая часов 16 работала. А выгрузить первичные данные — часа 2. Плюс код, который потом csv в 24 гига обрабатывает работал 40 минут на ноутбуке с i5-2450 и каким-то старым полудохлым винтом.

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

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

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

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

V>Все возможные варианты уже известны в compile-time.
Не угадал. Как я понимаю, это и является ключевым заблуждением во всех твоих странных теориях. Так вот, ответ — нет.
Все возможные варианты в compail-time не известны. Это, возможно, справедливо для пары довольно узких предметных областей, но в целом — нет.
И повторюсь, не надо растягивать свой куций опыт на всю индустрию.

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

V>Советую почитать букварь, начиная с буквы А. ))
Ты похоже начал со слова Ахамел? Советую усмирить комплекс отличника и чуть лучше разобраться в предмете.

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

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

Иллюстрация понятна, зачем ты её мне показал — совершенно непонятно.

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

Конкретно — поля типа массив, поиск по json полям, курсоры, lateral join, cte, nulls first, оконные функции, хинты, гибкое указание стратегии загрузки сущностей и так далее. Есть такие ORM, которые не поддерживают UPDATE по более чем одной сущности, например, зависит от конкретного ORM. Не может использовать потому, что не реализованы они там, не реализованы как правило потому, что ORM рассчитаны на использование с СУБД совместимыми со старым sql. Или потому, что рассчитаны на какой-то конкретный сценарий использования, зависит от конкретного ORM.

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

Какой ORM имеется в виду под хорошим? Если их много, то какие?

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

Чем её меньше в запросах, тем лучше. Но попадает периодически, это правда, никуда не денешься.

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

V>>Мусор в голове — мусор в словах.
MTD>Это уточняющий вопрос, так как высказался ты неоднозначно.

Я высказался однозначно, т.е. однозначными терминами из IT.

В ответ получил весь этот бред:

V>оба ендпоинта должны заранее знать тип возвращаемого результата,
V>а не гнать каждый раз метаинформацию и интерпретировать её на каждой из сторон.

Зачем нужна метаинформация?

V>Зачем она нужна прямо сейчас?
V>Потому что имеет место динамическая типизация, это ж классика жанра.

Зачем нужна метаинформация?

MTD>>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
V>Но язык доступа динамически типизированный.

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

И т.д. и т.п.
Как по мне, похоже на ведение беседы не приходя в сознание.


MTD>А ты стал юлить и выкручиваться, что странно, если ты понимаешь о чем говоришь.

Еще и нечистоплотен.


MTD>>>А все эти петабайты данных из астрала что-ли берутся?
V>>Я уже на этот ТУПЕЙШИЙ вопрос отвечал.
MTD>Где? Вопрос не тупой, вот на что он был задан:
MTD>

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

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


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

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


V>>Ты не работаешь, ты динамишь работодателя.
MTD>Ну так то работодателю видней, а не ноунейму из провинции.

С какой радости ему видней?
Смешно такое втирать на форуме программистов. ))

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


MTD>То было больше 6 лет назад, сейчас я могу значительно ловче.

Тю. За 6 лет можно научиться подробностям предметной области, особенностям языка и т.д., но невозможно кардинально поменять мыслительный аппарат. Особенно после возраста ~25-27-ми лет. Увы.

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

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

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

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


MTD>Посмотри пожалуйста мой актульный код и дай комментарии.

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

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

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

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

Кончается это плохо. Захочешь изменить структуру БД — завязнешь в возне с логикой, которая в сущностях. Плюс впринципе нехорошо, когда логика из одного слоя попадает в другой.

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

V>Потому что SQL безбожно устарел и вообще в современной разработке является сущностью второго рода — производной генерируемой хренью/абракадаброй.

Угу, сначала напридумают генераторов, потом начинают их "универсализировать", потом дописывать. Соответственно на выходе неоптимальные запросы, часто избыточные.
В итоге:
а) sql никто не знает
б) "эти ваши мускулепостгресы тормозят"

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

T>>>По идее ORM занимается построением типовых запросов и отображением таблиц в объекты, в которых логики быть РЕШИТЕЛЬНО НЕ ДОЛЖНО. Прямо вот так, капсом
F>>почему не должно?
T>Кончается это плохо. Захочешь изменить структуру БД — завязнешь в возне с логикой, которая в сущностях.

а так завязнешь в возне с логикой, которая в контроллерах.

T>Плюс впринципе нехорошо, когда логика из одного слоя попадает в другой.

слои — они в голове.
если объект выполняет логику, которая ему принадлежит(например, автомобиль генерит информацию о состоянии агрегатов), то чем это плохо?

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

S>Угу, сначала напридумают генераторов, потом начинают их "универсализировать", потом дописывать. Соответственно на выходе неоптимальные запросы, часто избыточные.
S>В итоге:
S>а) sql никто не знает
S>б) "эти ваши мускулепостгресы тормозят"

на практике получается так:
1. давайте заюзаем новую мегафичу из XZSQL. я прочитал на выходных в релиз нотесах
2. ой, надо кучу запросов переписать. и переписать их обработку
3. ой, надо выкинуть тулзу для миграций и накатать анальный sql-скрипт с ручной миграцией данных
4. ой, сроки просрали, проект закрыли
5. пишем на кывт посты о том, что все коллеги тупые

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

S>Угу, сначала напридумают генераторов, потом начинают их "универсализировать", потом дописывать. Соответственно на выходе неоптимальные запросы, часто избыточные.

Согласен, с этой автогенерацией SQL всё заведомо превращается в театр абсурда. ))
Как коллеги этого не замечают — ХЗ, если честно.
Наверно, глаз замылился.

Современный мейнстрим — это языки 3-го поколения.
SQL — 4-го.
Языки делятся на поколения сугубо по способам "общения" человека с машиной.

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

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

F>слои — они в голове.

Да всё структурирование кода оно для того, чтобы голове было легче с ним работать.

F>если объект выполняет логику, которая ему принадлежит(например, автомобиль генерит информацию о состоянии агрегатов), то чем это плохо?

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

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

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

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

Давно тебя не было, здарова.
С тобой мы обычно считаем нелогичности, помнишь, да?

Сходу:

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

Ответ — да, единственное, что может варьироваться в планах — это их варианты.
Тождественные планы я не рассматривал.

Раз.


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

Зато актуальность статистики зависит от объема и об этом было сказано там же.

Два.


V>> и текущего состояния пересчитанных индексов (их актуальности).
НС>Индексы в РСУБД всегда актуальны.

Реорганизация и перестроение индексов

Три.


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

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

Четыре.


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

Ну до тебя-то мне далеко, понятно.
Но давать борзеть собеседникам не люблю, есть такое.
Есть что сказать по-делу — говори.
Нет — свободен.

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

Пять.

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

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

Если это всё, что ты в состоянии ответить, то не стоило и начинать.
Ничего сложного мы пока не обсуждали.


IB>Ситуация, в довольно средних базах, когда объем кэша скомпилированных(!) планов превышает разумные пределы, является весьма не иллюзорной проблемой. Этот факт ни о чем не говорит?

Говорит о непонимании тобой причин этого, не?
1. Кол-во планов от кол-ва данных зависит не сильно, больше зависит от кол-ва таблиц, связей, индексов, характера данных и, самое главное, кол-ва уникальных запросов;
2. Планы уникальные на уникальные запросы; вернее, уникальные наборы планов;
3. Тождественность запросов в рантайме выявляется слабо, т.е. будучи переформулироваными, одинаковые по-сути запросы будут иметь разные наборы идентичных планов;
4. Фишку с "повторным использованием" частей планов даже разных запросов ты не понял, судя по-всему, но хамить торопишься.

Ты себе граф обхода вариантов при построении плана запросов нарисовал бы разок, коллега, и устыдился.

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

T>Может и тупик, но проблема эта — не проблема ORM. Это проблема языков, которые требуют на любой чих делать отдельный класс.
Нет. Это проблема — именно ORM. Потому что без ORM мы на тех же языках работаем с рекордсетами, которые не требуют порождать по классу на запрос. И прекрасно биндим их хоть в UI, хоть в бизнес-логику.
ORM претендуют на какую-то помощь, которой по факту не оказывают.

T>Это и есть кеш, да. Но сущности попадут в кеш независимо от того, как их загрузили — lazy или eager. Поэтому проблема возникает не из-за lazy load.
Eager load существует только как костыль к lazy load.
Напомню, что в обычном приложении до-ORMной эпохи нет никаких Eager Load — мы просто выполняем запрос и получаем результат. У нас нету "отображаемых объектов" с навигационными свойствами, которые, собственно, и провоцируют кэш, lazy load, и eager load, который должен изображать закат солнца вручную.

T>Ну я говорю ORM и имею в виду в первую очередь Hibernate. Так это не единственная альтернатива. А что ты имеешь в виду? Какие ORM?
Ну, EF. А что, в Hibernate уже появился способ сделать update stock set remainingQuantity=remainingQuantity-orderLine.orderedQuantity from select id, remainingQuantity from stock inner join orderLine on orderLine.stockItemId = stock.itemId where orderLines.OrderId = @orderID ?
И всё это дружелюбно к кэшу и всё такое?
Я на него много лет не смотрел

T>Да, повлияло, да уронило, да это проблема lazy load, но не та, про которую ты вначале говорил. Когда заранее знаешь, что lazy load мешает — надо включить eager.
Требование "знать заранее" напоминает мне старую сказку про порошок от блох — который надо сыпать в глаза каждой блохе.
Автоматический инструмент должен решать проблемы, а не создавать их. Требование вручную размечать код для устранения боттлнеков противоречит самой идее абстрагирования

T>>>то нарвёшься на проблему N + 1. Из-за lazy load.
S>>Надо понимать, что именно такой код не пишут почти никогда. Мы ж программисты — мы делаем Инкапсуляцию! Нужно среднее — добавляем студенту вычисляемое свойство AverageMark, с геттером, который бежит по коллекции StudentMarks.
S>>И биндим к гую вот эту вот коллекцию студентов, где в колонке 1 будет LastName, а в колонке 2 — AverageMark.

T>Я несколько раз написал, что так делать нельзя, когда используешь ORM. Увы.
Так проблема-то в том, что полноценные ORM вообще никакого решения для этого случая не предлагают.

T>Да, всё правда, именно поэтому не надо так делать. Да, абстракция течёт, но ORM не помогают абстрагироваться от БД полностью, они помогают упростить проведение типовых операций. Нутрянку БД при этом по-прежнему надо понимать.
Нет. Теперь надо понимать не только нутрянку БД, но ещё и нутрянку ORM. Ящетаю — в баню таких "помощников".
Вся эта помощь при проведении "типовых операций" сводится к "рисование формы master-detail", что прекрасно работало в Delphi 2 образца 1997 года безо всяких ORM.

T>Вот этот view ты замапишь на сущность в коде и будешь спокойно использовать.
Это хорошая идея. Только теперь у нас логика размазалась между тиерами, и чтобы что-то починить надо собирать вместе спеца по жаве и спеца по SQL.
Если я захочу засунуть логику в SQL, то я обойдусь средствами SQL, а ORM выкину на помойку, т.к. он мне вообще не помогает.


T>Не красиво и не ООПшно, но на то он и ORM.


T>Я считаю, что пока хороших инструментов нет, лучше не прятать базу далеко, во избежание.
Ну, linq2db движется в правильную сторону.

Здравствуйте, Terix, Вы писали:
T>А у меня наоборот было как-то. Была выгрузка из БД, которая часов 16 работала. А выгрузить первичные данные — часа 2. Плюс код, который потом csv в 24 гига обрабатывает работал 40 минут на ноутбуке с i5-2450 и каким-то старым полудохлым винтом.
Тут надо в код "выгрузки" смотреть.
Так-то я тоже в своё время отпахал на Обязательных Работах: чинил хранимки, написанные индусами. Типичное ускорение после починки — 50х.
Чуваки, которые пришли в SQL из клиппера (это я предполагаю), ухитрялись простейшие вещи делать вложенными курсорами.

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

F>>если объект выполняет логику, которая ему принадлежит(например, автомобиль генерит информацию о состоянии агрегатов), то чем это плохо?
T>Ты в структуру, которая является результатом, возвращаемым запросом хочешь поместить логику, которая генерирует другие запросы. Сложно даже объяснить чем это плохо, настолько это плохо . Наверно правильно вот так:
T>Утверждение, что сущность, которую ты достал из БД является объектом — неверно. Объект обладает поведением и инкапсулирует состояние. Сущности этого не делают — это просто мешок данных. Возможно было бы лучше вообще засунуть их в ассоциативный массив, чтобы не возникало желания делать методы.

короче, это плохо, потому что тебе не нравится. твоя позиция понятна.