Здравствуйте, IT, Вы писали:
V>>Внешний синтаксис вполне. V>>Промежуточное представление — мрак. V>>Дерево экспрешшенов в рантайме — хана всему. IT>Второе и треье вроде одно и то же.
Да, третье — объяснение второго.
Re[10]: В России опять напишут новый объектно-ориентированны
Здравствуйте, MTD, Вы писали:
V>>Через типизированный язык. V>>В базе-то сидит реляционная алгебра, а она строго типизирована. V>>Отношения — они строго типизированы. MTD>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
Но язык доступа динамически типизированный.
V>>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их. MTD>Пример?
Кучи хранилищ данных с одинаковой разметкой таблиц.
Или кучи таблиц с одинаковой разметкой внутри одного хранилища.
V>>1. Типобезопасность, помощь со стороны компилятора; V>>2. Мощные, выразительные ср-ва языка; V>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений; MTD>А чего из перечисленного нет в Фортране?
1, 2
Система типов убогая.
V>>В итоге — готовность работать с современными гигабитными сетками. V>>Мейнстримовые БД с такими сетками работать де-факто не готовы. MTD>А все эти петабайты данных из астрала что-ли берутся?
С нормальной скоростью они только через bulk залетают.
V>>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным. V>>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их. MTD>Это булшит.
Сразу досвидан. ))
V>>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет". MTD>Я такое говорил? Нет? А к чему ты это написал?
Потому что это основной и единственный аргумент в обсуждениях такого рода.
Твой "булшит" тому подтверждение.
V>>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой. MTD>Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
Это весь комплекс телодвижений по вводу запроса и выводу результата.
V>>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы. MTD>>>Опять бла-бла-бла. Конкретней. V>>Это было более чем конкретно. MTD>Нет — это бла-бла-бла.
Это через запятую перечислены ключевые моменты.
Спорь с этими моментами или слил.
V>>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка. MTD>Ну вот и говори про него, пока ничего конкретного не сказал.
Сказано было достаточно — динамика vs статика.
V>>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду. V>>Это хорошо объясняется на всех углах и без меня. MTD>А при чем тут языки с динамической типизацией?
При языке SQL и формате данных, пересылаемых по сети.
V>>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм. MTD>>>Как? V>>Как в С++, Java/Net, Swift и т.д. MTD>Мы про БД говорим. Как?
Мы про реляционную алгебру говорим.
Так же.
V>>Форматы хранения даных в различных БД открыты, спор ни о чём. MTD>Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
Ты показал невежество.
Как и сообщением раньше:
Или на примере сокета — ... по дороге это просто байты
В оперативной памяти тоже просто байты хранятся.
Соблюдение типизации выражается в правильном интерпретировании этих байт.
Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается.
Там же, на стороне клиента, каждый раз при обращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому.
Т.е., мало того, что информация копируется малюсенькими куусочками — по одному значению одного поля каждый раз, так еще вокруг этого миллион телодвижений. При соблюдении же типизации можно сразу возращать ссылку на типизированное представление строки данных — некую структуру.
MTD>Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
Пока не разберёшься, чем отличается статическая типизация от динамической — это будет разговор ни о чём.
Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
MTD>По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
Твои вопросы не относятся к сути моих предложений от слова никак. ))
Пока что ты пытаешься разобраться в отличии статики от динамики, но я уже отказался в этом участвовать (в прошлом сообщении).
Здравствуйте, vdimas, Вы писали:
MTD>>Я не понимаю, ты же сам пишешь, что на сервере уже все типизировано.
V>Но язык доступа динамически типизированный.
С++ тоже динамически типизирован? Он же читает байты из сокета или файла, например.
V>>>Это приведёт к еще одной разновидности оптимизации — повторному использованию кода, бо "тип" может быть отделён от "экземпляра", что тоже кардинально развяжет руки разработчикам. Потому что "мыслить категориями доменов" уместно далеко не во всех сценариях вокруг хранения данных. Я бы даже предположил — в подавляющем меньшинстве их. MTD>>Пример?
V>Кучи хранилищ данных с одинаковой разметкой таблиц. V>Или кучи таблиц с одинаковой разметкой внутри одного хранилища.
Так уже. Или пример я не понял.
V>>>1. Типобезопасность, помощь со стороны компилятора; V>>>2. Мощные, выразительные ср-ва языка; V>>>3. Оптимизация, выкидывание лишних артефактов и лишних телодвижений; MTD>>А чего из перечисленного нет в Фортране?
V>1, 2 V>Система типов убогая.
Что не так?
V>>>В итоге — готовность работать с современными гигабитными сетками. V>>>Мейнстримовые БД с такими сетками работать де-факто не готовы. MTD>>А все эти петабайты данных из астрала что-ли берутся?
V>С нормальной скоростью они только через bulk залетают.
Ты снова не конкретен. Если речь о трупут, то справедливо вообще для всего, от ОЗУ до дисков групировать маленькие порции и вываливать все сразу. Если о латенси, то bulk будет вреден. Кстати, ты слился с вопросом про производительность БД, а я так ждал.
V>>>Сам я последние много лет работаю именно с протоколами удалённого доступа к данным. V>>>Средний современный roundtrip (вопрос-ответ) составляет единицы микросекунд или единицы десятков их. MTD>>Это булшит.
V>Сразу досвидан. ))
Но это в самом деле булшит.
V>>>Поэтому, мне ОЧЕНЬ сложно участвовать в обсуждениях вокруг БД, где основными аргументами являются примерно такие: "да там всё равно СТОЛЬКО НАКЛАДНЫХ РАСХОДОВ, что экономить на спичках смысла нет". MTD>>Я такое говорил? Нет? А к чему ты это написал?
V>Потому что это основной и единственный аргумент в обсуждениях такого рода.
Но я же это не говорил. Зачем ты мне это приписал? Ай, ай, некрасиво.
V>>>Современные технологии как сетки, так и технологии работы БД с данными (особенно после "разогрева" с учётом нынешних чудовищных размеров оперативки) таковы, что основные тормоза приходятся именно на "интерфейсный" уровень БД. Этот уровень затормаживает всю систему в большинстве сценариев на порядок-другой. MTD>>Это полная чушь или уточни, что ты подразумеваешь под "интерфейсный".
V>Это весь комплекс телодвижений по вводу запроса и выводу результата.
Давай конкретику, твое бла-бла-бла наводит на мысль, что в твоей голове кроме лозунгов ничего нет.
V>>>>>В выразительных возможностях языка, в системе типов, в завязанной на этих моментах оссобеностях транспортного и прикладного уровня протоколов общения с БД и ничтожной в итоге эффективности всей системы. MTD>>>>Опять бла-бла-бла. Конкретней. V>>>Это было более чем конкретно. MTD>>Нет — это бла-бла-бла.
V>Это через запятую перечислены ключевые моменты. V>Спорь с этими моментами или слил.
Спорить с чем? Давай конкретные тезисы, а не бла-бла-бла.
V>>>Я говорил о языке (или языках, не суть), предназначенном для обработки данных и инфраструктуре вокруг этого языка. MTD>>Ну вот и говори про него, пока ничего конкретного не сказал.
V>Сказано было достаточно — динамика vs статика.
И? Разверни мысль.
V>>>Зачем нужна метаинформация в случае динамической типизации я объяснять не буду. V>>>Это хорошо объясняется на всех углах и без меня. MTD>>А при чем тут языки с динамической типизацией?
V>При языке SQL и формате данных, пересылаемых по сети.
Ничего не понял, ты считаешь, что С++ динамически типизированный язык?
V>>>>>Тезисы я озвучивал — перенос кучи телодвижений из рантайма в компайлтайм. MTD>>>>Как? V>>>Как в С++, Java/Net, Swift и т.д. MTD>>Мы про БД говорим. Как?
V>Мы про реляционную алгебру говорим. V>Так же.
Ну так как?
V>>>Форматы хранения даных в различных БД открыты, спор ни о чём. MTD>>Никто не спорит, тебе просто показали, что байты ни про какую типизацию не в курсе.
V>Ты показал невежество.
Я просто задавал вопросы. Ты надувал щеки и лил воду.
V>Как и сообщением раньше: V>
V>Или на примере сокета — ... по дороге это просто байты
V>В оперативной памяти тоже просто байты хранятся.
Молодец. Еще немного и сдвинемся.
V>Соблюдение типизации выражается в правильном интерпретировании этих байт.
Да.
V>Сейчас типизация динамическая, что влечёт за собой дополнительные расходы.
Где? Когда С++ принимает пакет по сети? Ну да, а что делать?
V>Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается.
Сто лет такое есть.
V>Там же, на стороне клиента, каждый раз при обращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому.
Сто лет такое есть.
V>Т.е., мало того, что информация копируется малюсенькими куусочками — по одному значению одного поля каждый раз, так еще вокруг этого миллион телодвижений.
Откуда инфа про маленькие кусочки? Пруф давай.
V>При соблюдении же типизации можно сразу возращать ссылку на типизированное представление строки данных — некую структуру.
В смысле взять структуру и ее бинарное представление сохранить, а потом прочесть и скастить? Не знаешь, почему это плохая идея?
MTD>>Так и в БД все типизировано и не поверишь — там тоже есть оптимизатор. Твои идеи, или просто потрындеть?
V>Пока не разберёшься, чем отличается статическая типизация от динамической — это будет разговор ни о чём.
Так разберись.
V>Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный.
То есть про БД ты ничего не знаешь, но мнение имеешь?
MTD>>По моему ты увлекся беседой с выдуманным собеседником. Может со мной поговоришь? Начни для начала отвечать на заданные вопросы.
V>Твои вопросы не относятся к сути моих предложений от слова никак. ))
Просто они для тебя неудобные, а как взрослый человек поступить ты не в силах.
Re[10]: В России опять напишут новый объектно-ориентированны
GeneXus applications are not just data-driven; they are built to harness your most important business data, e.g. Core Banking, ERPs, CRMs.
В разных системах/языках есть разные удачные моменты, а есть не очень.
Но беда всех их примерно как у SQL — они все уже малость устарели (с т.з. именно языка), хотя некоторые из этих языков/систем активно используюся в современных нагруженных приложениях.
Здравствуйте, MTD, Вы писали:
MTD>С++ тоже динамически типизирован? Он же читает байты из сокета или файла, например.
Пипец...
MTD>Кстати, ты слился с вопросом про производительность БД, а я так ждал.
Я тебе уже отвечал — единицы/десятки микросекунд на ответ.
Именно такие БД обслуживают крупнейшие биржи, системы сотовой связи или крупные узлы интернет-роутинга.
А ты, наверно, думал про MS SQL или Orace? ))
Ты как с другой стороны Луны, коллега.
В типизациях плаваешь, про современные БД не в курсе.
[много скипнул, бо пошли уже по кругу]
Например:
V>>Сейчас типизация динамическая, что влечёт за собой дополнительные расходы. MTD>Где? Когда С++ принимает пакет по сети? Ну да, а что делать?
Мне действительно не интересно рассказывать, как в С++ можно принимать пакеты по сети без всякой динамической типизации.
Я не надуваю щёки, коллега, просто это отдельная тема, оффтоп.
RTFM.
V>>Например, на стороне клиента нужно динамически выбрать маппер из типа, хранимого в столбце, в тип переменной, куда это поле читается. MTD>Сто лет такое есть.
Да. Зло и нубство а-ля BASIC из середины 70-х годов.
V>>Там же, на стороне клиента, каждый раз при обращении к клиентскому драйверу при запросе значения некоторого поля текущей записи, драйвер тоже проверит — может ли он преобразовать тип данных в этом поле к запрашиваемому. MTD>Сто лет такое есть.
Дык, скоро 50 лет этой технике.
Не пора ли отправить на помоечку?
Современные эффективные системы уже давным давно давно так не пишутся.
Потому что уже относительно давно размеры оперативки позволяют немного раздуть код ради исключения лишних телодвижений в рантайме.
Согласись, что лишние 3-5 мег бинарного кода (после оптимизации) в пересчёте на сервак сегодня никто не заметит.
При этом можно будет выкинуть примерно 5-10 мег "динамического движка", который сегодня живёт в знакомых тебе DBMS.
MTD>В смысле взять структуру и ее бинарное представление сохранить, а потом прочесть и скастить? Не знаешь, почему это плохая идея?
Ну ты же так делаешь с оперативной памятью?
Я тебе больше скажу — даже когда по сети гоняются данные с динамической типизацией — то сама-то метаинформация над этой динамической типизацией, она ведь строго типизированная!
V>>Я лишь делился наблюдениями из своей предметной области, где зачастую весь прикладной трафик строго-типизированный. MTD>То есть про БД ты ничего не знаешь, но мнение имеешь?
Это попахивает тем твоим советом "почитать про хранимые процедуры".
Коллега, ты реально с другой стороны Луны. От современного IT малость далёк.
V>>Твои вопросы не относятся к сути моих предложений от слова никак. )) MTD>Просто они для тебя неудобные, а как взрослый человек поступить ты не в силах.
Почему? Я как раз запросто, тот еще любитель называть вещи своими именами.
Просто конкретно в нашей ситуации если, то меня сходу забанят. ))
Здравствуйте, MTD, Вы писали:
MTD>Просто они для тебя неудобные, а как взрослый человек поступить ты не в силах.
Да это он просто в очередной раз "изобрёл" идею оптимизировать коммуникацию между клиентом и сервером — путём отправки "туда" байткода (AST) вместо текстового SQL и отправки обратно какого-то "более оптимального" формата по сравнению с Tabular Data Stream.
Поскольку никаких конкретных данных ни о том, сколько времени тратится на генерацию и парсинг SQL по сравнению со временем исполнения реального запроса, ни о том, как устроен TDS и что там можно сэкономить, у него нет, мы и наблюдаем вот это вот беспредметное надувание щёк и называние всех собеседников идиотами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Terix, Вы писали:
T>Много раз слышал от разных людей. Для начала пара слов про производительность. С производительностью проблема возникает от того, что ORM тупо не поддерживают плюхи конкретных СУБД. И приходится использовать нативный sql, чтобы их заюзать.
Нет. Основная проблема с производительностью в ОRM — в том, что вместо уместных запросов (типа select sum(orderdetail.total) as order total from orderdetail where orderid = @orderId) они провоцирут писать навигационный код в стиле var orderTotal = 0.0; foreach (orderDetail in order.Details) orderTotal += orderDetail.total;
Всё остальное — уже последствия.
T>Бизнес логика, да, может меняться независимо от БД, поэтому, повторюсь нельзя помещать логику в объекты, отображением которых в БД занимается ORM. А лучше вообще не показывать эти объекты коду, который занимается бизнес-логикой. Данные в базе это данность, но вот структура БД может и будет меняться так же, как и бизнес логика. И очень удобно, когда можно менять одно независимо от другого.
Для этого пригодна только анемичная модель и light-wight ORM, которые не предлагают ни lazy load, ни unit of work.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Нет. Основная проблема с производительностью в ОRM — в том, что вместо уместных запросов (типа select sum(orderdetail.total) as order total from orderdetail where orderid = @orderId) они провоцирут писать навигационный код в стиле var orderTotal = 0.0; foreach (orderDetail in order.Details) orderTotal += orderDetail.total; S>Всё остальное — уже последствия.
Если ORM не позволяет написать запрос с каунтом или написать код, который сгенерирует такой запрос — это проблема ORM. У нормальных ORM такой проблемы нет. Если программист сам не пользуется возможностями ORM — это проблема квалификации программиста.
S>Для этого пригодна только анемичная модель и light-wight ORM, которые не предлагают ни lazy load, ни unit of work.
Речь не об анемичности модели, речь о том, что ORM преобразует таблицы БД в структуры из языка программирования. Вокруг этого преобразования можно наворотить Rich Model, надо только помнить, что объекты от ORM — только для передачи данных. lazy load полезная штука, которая ортогональна вопросу использования объектов, сгенерированных ORM, только для передачи данных из БД в код и обратно. И с unit of work та же история.
Re[13]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
MTD>>Просто они для тебя неудобные, а как взрослый человек поступить ты не в силах. S>Да это он просто в очередной раз "изобрёл" идею оптимизировать коммуникацию между клиентом и сервером — путём отправки "туда" байткода (AST)
Боже упаси ))
Это будет та еще нелепость, прибивающая всю идею на корню.
Я вообще ХЗ как можно было додуматься сэкономить только на построении AST запроса.
S>вместо текстового SQL и отправки обратно какого-то "более оптимального" формата по сравнению с Tabular Data Stream.
Обратно должны идти просто типизированные данные, т.е. в заведомо известной обеим сторонам разметке.
Прямо сейчас всё это уже есть и отлично работает в упомянутых мною областях.
Но стек технологий при этом получается "разорван", отсюда невыразителен и, скажем прямо, убог по меркам 2017-го года.
Не так убог как динамическая SQL-технология образца середины 70-х, используемая поныне, но всё-равно можно было давно сделать как-то иначе.
Собсно, что-то типа протоколов передачи строготипизированных данных в OLE (где typelib формируется как артефакт компиляции), только заточенное на обмен данными-сообщениями, а не синхронный вызов методов.
S>Поскольку никаких конкретных данных ни о том, сколько времени тратится на генерацию и парсинг SQL по сравнению со временем исполнения реального запроса
Мы это уже проходили как-то именно с тобой и со всеми временами.
Когда данные из разогретой базы достаются прямиком из оперативки (а таких будет 99.99% случаев в тех самых нагруженных сценариях), то они достаются за единицы/десятки микросекунд.
S>ни о том, как устроен TDS ... называние всех собеседников идиотами.
Ну ты-то спешишь обычно обвинить окружающих до того, как в чём-то убедился, верно?
Ну, типа, чтобы сразу взбодрить окружающих? ))
А я тут тщательно повторял, чего именно я собираюсь избегать.
Но пока что мы дальше отличий динамической типизации от статической не продвинулись.
Причём, коллега проявляет удивительную настойчивость в нежелении продвигаться.
Его демократическое право.
Здравствуйте, Sinclair, Вы писали:
S>Нет. Основная проблема с производительностью в ОRM — в том, что вместо уместных запросов (типа select sum(orderdetail.total) as order total from orderdetail where orderid = @orderId) они провоцирут писать навигационный код в стиле var orderTotal = 0.0; foreach (orderDetail in order.Details) orderTotal += orderDetail.total;
Ты из какого года пишешь? ))
Есть языки и/или расширения к имеющимся (к С++, например), которые переводят второе в первое.
То бишь, параллелят, если данные уже в памяти.
S>Всё остальное — уже последствия.
Это последствия устаревших технологий и устаревших же рассуждений.
T>>Бизнес логика, да, может меняться независимо от БД, поэтому, повторюсь нельзя помещать логику в объекты, отображением которых в БД занимается ORM. А лучше вообще не показывать эти объекты коду, который занимается бизнес-логикой. Данные в базе это данность, но вот структура БД может и будет меняться так же, как и бизнес логика. И очень удобно, когда можно менять одно независимо от другого. S>Для этого пригодна только анемичная модель и light-wight ORM, которые не предлагают ни lazy load, ни unit of work.
Ну, начнём с того, что постановка вопроса "удобства" во главу угла является ошибкой, бо это не первопричина, а следствие. Это удобство сегодня требуется из-за тотального разрыва в стеке технологий в случае "обычного SQL" и является лишь способом адаптации разработчиков к такому разрыву.
Но уже относительно давно есть успешно используемые компиллируемые технологии, на которых обработка данных не отделена от их объявления/типизации (иначе компиллируемости не будет). Причём, некоторые из этих технологий основаны на очень даже неплохих "полноценных движках БД" унутре, не уступающих MS SQL (если у того убрать SQL и всё вокруг него, а оставить только подсистему хранения/выборки данных с учётом транзакций, индексов и т.д.).
V>Но уже относительно давно есть успешно используемые компиллируемые технологии, на которых обработка данных не отделена от их объявления/типизации (иначе компиллируемости не будет).
Это какие технологии? Прямо названия можно, дальше я погуглю.
И вообще вопрос — как можно не разделить хранение данных и их обработку, при этом не создав плохой код? Можно отказаться от sql — ноу проблем, но данные то всё равно надо будет в каком-то виде передавать из хранилища в приложение.
T>И вообще вопрос — как можно не разделить хранение данных и их обработку, при этом не создав плохой код? Можно отказаться от sql — ноу проблем, но данные то всё равно надо будет в каком-то виде передавать из хранилища в приложение.
Навскидку, несколько популярных подходов:
* Всё это делается прозрачно для программиста на том же самом языке, т.е. в той же среде.
Cовсем грубое сравнение — как в 1С, где типы таблиц не отделимы от кода, их обрабатывающих; разве что в 1С нет компиллируемости.
* И/или генерятся заголовки для С/С++ и соответствующая клиентская библиотека для этой базы.
Такой подход применяют биржи типа NASDAQ, SQX, крупные банки и прочие системы на основе OMnet/OMX-технологий.
Здравствуйте, vdimas, Вы писали:
V>Навскидку, несколько популярных подходов:
V>* Всё это делается прозрачно для программиста на том же самом языке, т.е. в той же среде.
ORM, как он есть. В бизнес логику структуры, которые представляют голые данные — лучше не пихать.
V>Cовсем грубое сравнение — как в 1С, где типы таблиц не отделимы от кода, их обрабатывающих; разве что в 1С нет компиллируемости.
Если у тебя бизнес сущности с колторыми ты работаешь — и есть таблицы, то может и работает подход.
V>* И/или генерятся заголовки для С/С++ и соответствующая клиентская библиотека для этой базы. V>Такой подход применяют биржи типа NASDAQ, SQX, крупные банки и прочие системы на основе OMnet/OMX-технологий.
Так это же тоже один из вариантов ORM. Тоже, логику нельзя класть в сгенерированные классы из заголовков и их сами нежелательно в бизнес логику.
Здравствуйте, Terix, Вы писали: T>Если ORM не позволяет написать запрос с каунтом или написать код, который сгенерирует такой запрос — это проблема ORM.
Именно. Об этом я и говорю. T>У нормальных ORM такой проблемы нет. Если программист сам не пользуется возможностями ORM — это проблема квалификации программиста.
Список нормальных ORM — в студию! S>>Для этого пригодна только анемичная модель и light-wight ORM, которые не предлагают ни lazy load, ни unit of work. T>Речь не об анемичности модели, речь о том, что ORM преобразует таблицы БД в структуры из языка программирования.
Вот именно. При этом мы понимаем, что помимо "таблиц" в RDBMS существенную роль играют view, table-valued functions, и прочий ad hoc.
Традиционные "full-blown" ORM из всего этого умеют готовить только таблицы и, немножко, view. T>Вокруг этого преобразования можно наворотить Rich Model, надо только помнить, что объекты от ORM — только для передачи данных. lazy load полезная штука, которая ортогональна вопросу использования объектов, сгенерированных ORM, только для передачи данных из БД в код и обратно. И с unit of work та же история.
Нет. И то и другое — штука вредная. Поясняю на пальцах: как только у вас появился lazy load, у вас появился кэш. Вместе с обязанностями по его поддержке в свежем состоянии. То есть если я скормил в базу хорошо структурированный запрос, типа "провести ордер" из теста TPC-C, у меня всё, что было lazy loaded, надо сразу отправлять на помойку, т.к. нет способа определить, какие из загруженных объектов устарели.
Если у меня есть незакрытый unit of work, то я не имею права в этой же транзации пользоваться "запросом с каунтом", т.к. он увидит только то, что есть в RDBMS.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: В России опять напишут новый объектно-ориентированны
Здравствуйте, vdimas, Вы писали:
V>Я вообще ХЗ как можно было додуматься сэкономить только на построении AST запроса.
Ну я просто предположил, что у любого безумия есть пределы. Скажем, выполнять оптимизацию плана исполнения в компайл-тайм — это гарантировать себе хреновую производительность на века. Потому что в компайл-тайм у нас нет статистики по реальным данным (а у сервера в рантайм — есть). Поэтому максимум, что мы можем отправить — это тот самый декларативный запрос в терминах RA, без каких-либо деталей о плане исполнения.
А это и есть AST — за подробностями рекомендую почитать любой учебник по проектированию СУБД.
ю с Tabular Data Stream.
V>Обратно должны идти просто типизированные данные, т.е. в заведомо известной обеим сторонам разметке.
Подсказка: прямо сейчас это так и есть. V>Прямо сейчас всё это уже есть и отлично работает в упомянутых мною областях.
Чтобы аргументированно продолжать этот спор, нужно показать, как выглядит бинарное представление результата запроса select top 10 from orders order by orderDate desc в TDS, а уже затем предложить "революционные изменения".
Заодно убедительно продемонстрировать, в чём именно этот новый формат будет лучше существующего. V>Когда данные из разогретой базы достаются прямиком из оперативки (а таких будет 99.99% случаев в тех самых нагруженных сценариях), то они достаются за единицы/десятки микросекунд.
Да-да, я помню. И данных про то, сколько занимает разбор запроса и формирование ответа как не было так и нет. V>Причём, коллега проявляет удивительную настойчивость в нежелении продвигаться.
Продвигаться некуда. Вы, коллега, традиционно избегаете упоминания любых технических деталей, отделываясь бессмысленными намёками.
Как я уже говорил, эта манера беседы прекрасно подходит для охмурения первокурсниц ИТ-специальностей.
Чтобы произвести впечатление на профессионалов, придётся привести что-то конкретное. Понятное дело, с риском потерять возможность вильнуть в сторону, сделав вид, что "да я совсем не это имел в виду".
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали: V>Ты из какого года пишешь? ))
Из 2018. V>Есть языки и/или расширения к имеющимся (к С++, например), которые переводят второе в первое. V>То бишь, параллелят, если данные уже в памяти.
Ничего не получится. На всякий случай напомню, что речь — про lazy load, и невинная итерация по коллекции orders скрывает за собой возможный раундтрип до СУБД. V>Ну, начнём с того, что постановка вопроса "удобства" во главу угла является ошибкой, бо это не первопричина, а следствие. Это удобство сегодня требуется из-за тотального разрыва в стеке технологий в случае "обычного SQL" и является лишь способом адаптации разработчиков к такому разрыву.
Это как раз первопричина. Нужно понимать, что данные — это факты. Трактовка этих фактов (бизнес-правила) меняются по пять раз в квартал. А вот сами данные остаются теми же самыми. И разрыв в стеке технологий тут совершенно ни при чём.
Разрыв в стеке технологий — это то, что сам SQL спроектирован плохо. Он же был рассчитан на одноразовые интерактивные запросы. Там почти что нет возможностей по декомпозиции, из-за чего на нём невозможно писать мало-мальски сложную логику. Потому-то создатели ентерпрайз-приложений и сбежали из хранимок в яву — то есть от клиент-сервера к трёхзвенке. После ужасов тридцатистраничных хранимок даже ява с её бесконечными factory bean кажется глотком свежего воздуха.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Terix, Вы писали:
T>Так это же тоже один из вариантов ORM. Тоже, логику нельзя класть в сгенерированные классы из заголовков и их сами нежелательно в бизнес логику.
Ограничений явного плана на такие вещи нет и быть не может.
Это тебя не в ту сторону занесло.
Ты спросил о том, как "выглядит" технология для разработчика — я ответил.
Здравствуйте, Sinclair, Вы писали:
V>>Я вообще ХЗ как можно было додуматься сэкономить только на построении AST запроса. S>Ну я просто предположил, что у любого безумия есть пределы. Скажем, выполнять оптимизацию плана исполнения в компайл-тайм — это гарантировать себе хреновую производительность на века.
Слабовато с воображением.
S>Потому что в компайл-тайм у нас нет статистики по реальным данным (а у сервера в рантайм — есть). S>Поэтому максимум, что мы можем отправить — это тот самый декларативный запрос в терминах RA
А сколько всего может быть вариантов плана у среднего запроса?
Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
И еще в прошлый раз, когда мы обсуждали все эти вещи, я обращал твоё внимание на "повторное использование".
Например, согласно предметной области одни и те же данные в запросах часто встречаются во вполне конкретной конструкции join или её разновидности. Соответственно, всё мн-во всех вариантов планов запросов при суммировании их по всем де-факто имеющимся запросам, получается сильно ниже простой суммы всех вариантов по всем запросам.
И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
И даже с тем гипотетическим примером, приводимым в прошлый раз, когда кол-во условий зависело от каких-то флагов в ГУИ — вот прямо эти флаги в запросе и подашь, а его конкретный вид сформируется уже на сервере, т.е. эта логика из клиента уходит. ))
По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.
S>без каких-либо деталей о плане исполнения.
Без самого декларативного запроса.
Я же сразу сказал — поменяется сам принцип разработки.
Сейчас данные живут вместе с кодом в базе и сверху этого еще динамические запросы.
Придётся отделить данные от кода, код будет теперь зависеть только от схемы, а не от конкретного хранилища.
А динамическими останутся только параметры некоторых запросов.
Иначе мы ведем разговор не о статике, а не понятно о какой химере, которую ты себе вообразил. ))
S>А это и есть AST — за подробностями рекомендую почитать любой учебник по проектированию СУБД.
"Иди познакомься с синтаксисом хранимых процедур" (С)
V>>Обратно должны идти просто типизированные данные, т.е. в заведомо известной обеим сторонам разметке. S>Подсказка: прямо сейчас это так и есть.
Классный залёт.
"Это" становится известным в рантайм, а не компайл-тайм.
Подсказка: "Иди познакомься с синтаксисом хранимых процедур" (С)
V>>Прямо сейчас всё это уже есть и отлично работает в упомянутых мною областях. S>Чтобы аргументированно продолжать этот спор, нужно показать, как выглядит бинарное представление результата запроса select top 10 from orders order by orderDate desc в TDS, а уже затем предложить "революционные изменения".
Я дал все ключевые слова по которым можно выйти прямо на спеки некоторых бирж и там в доке найти ответы на все вопросы.
Для некоторых можно даже без регистрации скачать C-заголовки типизированных запросов + реализующие клиентские библиотеки.
S>Заодно убедительно продемонстрировать, в чём именно этот новый формат будет лучше существующего.
Наверно тем лучше, что в высокоскоростной сетке другого-то подхода и не используют.
Можно я сделаю вид, что и сам не понимаю — а как же так могло получиться-то? ))
V>>Когда данные из разогретой базы достаются прямиком из оперативки (а таких будет 99.99% случаев в тех самых нагруженных сценариях), то они достаются за единицы/десятки микросекунд. S>Да-да, я помню. И данных про то, сколько занимает разбор запроса и формирование ответа как не было так и нет.
Так вычти одно из другого, какие проблемы?
Получишь разницу.
Там до порядка разница в нормальном режиме работы, т.е. вот уже биржа стартовала и пошла разгребать чудовищный трафик событий — т.е. база уже через секунды будет хорошо "разогрета" и такой и будет оставаться до конца рабочего дня.
V>>Причём, коллега проявляет удивительную настойчивость в нежелении продвигаться. S>Продвигаться некуда. Вы, коллега, традиционно избегаете упоминания любых технических деталей, отделываясь бессмысленными намёками.
Вот почему вместо того, чтобы честно признаться в недостатке воображения, в неспособности увидеть отличия м/у сценариями статической и динамической типизации, надо обязательно искать виноватых на стороне?
Я пока мест жду, пока у тебя в голове что-то щелкнёт и ты начнёшь сам себя останавливать в своих аргументах, по принципу: "ан нет, аргумент не годный, там же статика". И начнёшь думать на шажок дальше. И тогда сам характер твоих вопросов поменяется на примерно такие: "а как в статике делать то-то и то-то", т.е. я сразу увижу, что разговариваю с осмысленным собеседником, а не лишь бы ля-ля-ля.
S>Как я уже говорил, эта манера беседы прекрасно подходит для охмурения первокурсниц ИТ-специальностей.
Пока что ты даже и не начинал включать голову, чтобы отстреливаться шаблонными фразами.
Не заслужил ты пока шаблонности в этом споре.
Попробуй еще раз.
Или тупо забей, если накатила лень ума.
Re[16]: В России опять напишут новый объектно-ориентированны
Здравствуйте, vdimas, Вы писали:
V>А сколько всего может быть вариантов плана у среднего запроса?
Начнем с того, что средний запрос не интересен, но дело даже не в этом.
V>Дай угадаю. Вначале тебе захотелось воскликнуть "да сколько угодно", а по факту — дудки, весьма счётное кол-во.
В целом да, количество счетное, только считать устанешь. Как думаешь, насколько редок сценарий, когда сиквел перестает перебирать варианты планов, так как перебирать дальше дороже, чем исполнить наиболее эффективный из имеющихся?
V>Например, согласно предметной области одни и те же данные в запросах часто встречаются во вполне конкретной конструкции join или её разновидности. Соответственно, всё мн-во всех вариантов планов запросов при суммировании их по всем де-факто имеющимся запросам, получается сильно ниже простой суммы всех вариантов по всем запросам.
Это даже комментировать не интересно.
V>И да. Ты не догадался о самом главном — все запросы уже есть. Динамически подаются только их параметры.
Проблема только в том, что план запроса может зависеть от параметра, то есть само значение параметра влияет на то каков должен быть план, что драматически увеличивает число возможных вариантов.
V>По крайней мере так это работает в современных нагруженных системах обработки данных — банкинг, биржи, диспетчеризация сотовой связи и т.д.
Советую ознакомиться с тем, как это работает в SQL БД последние лет тридцать.
S>>Продвигаться некуда. Вы, коллега, традиционно избегаете упоминания любых технических деталей, отделываясь бессмысленными намёками.
+1
Мы уже победили, просто это еще не так заметно...
