Здравствуйте, neFormal, Вы писали:
F>короче, это плохо, потому что тебе не нравится. твоя позиция понятна.
А твоя позиция — это хорошо, потому что нравится тебе.
У тебя был аргумент — почему не добавить к объекту методы, которые реализуют логику, которая ему принадлежит. Мой — сущности, которые ты вытаскиваешь из БД объектами не являются, поэтому твой аргумент тут не применим.
Re[19]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
V>>Учу читать: V>>over 1 million transactions per second S>facepalm. Сначала сам научись читать. Сопоставлять приведённые цифры. Вот, скажем, сколько сообщений в секунду они обрабатывают? S>В среднем — 1.7 миллиона. Я так полагаю, что это и есть те самые "over 1 million transactions", потому что иначе окажется, что транзакция в среднем соответствует 1.2-1.5 сообщениям,
Блин, ты умудряешься проявлять даже большую недогадливость, чем я мог себе позволить предположить в отношении тебя.
Я еще помню твой живой ум в середине 2000-х.
Кароч.
* Не на каждое сообщение случается транзакция на бирже.
Запрос справочных данных, статистики и т.д. — это всё "сообщения без последствий".
* в одном сообщении может содержатся несколько запросов или несколько ответов;
* Из одного твоего сообщения может случиться сотни транзакций.
Например, ты выставил лот 1000 штук акций, сколько-то из них покупали в течении дня, всего было 200 сделок.
* одним сообщением можно выставить десятки/сотни разных лотов.
* в одном сообщении тебе может придти оповещение о многих свершённых транзакциях;
* Итого, трафик сообщений в штуках не равен трафику транзакций в штуках.
* Транзакция биржи не равна транзакции в БД. Транзакция биржи — это "сделка".
* Транзакции в БД возникают, даже когда не происходит сделок, например, когда ты выставляешь, корректируешь или снимаешь лоты.
* На каждую транзакцию биржи приходится десятки "просто запросов" + "просто транзакций в терминах БД".
S>Пиковая нагрузка — вдвое выше. Это по официальным данным, а не высосанным из пальца.
Это официальные, но не технические данные, потому что использован соотв. журналистский, а не технический язык.
Тем более, это за 2013-й год, с тех пор пропускная способность биржи возросла, а значит, возросли колебания, которые ранее сглаживались за счёт более длинных в среднем очередей. Это ж классика ТМО (теория очередей).
Мои наблюдения за колебаниями на биржах чуть свежее.
S>Ок, Nasdaq молодцы, могут до примерно 2х с копейками миллионов транзакций в секунду.
Биржевых транзакций.
V>>Т.е. всё еще на примерно пару порядков меньше требуемого, с учётом колебаний нагрузки и трафика запросов, резко превышающего трафик транзакций? )) S>Как видим. не так уж и резко.
Я сразу давал свои оценки в диапазоне 1-2 порядка.
Как раз полтора порядка ближе всего к истине.
V>>Твой MS SQL умеет делать полмиллиона добавлений одной строчки в одну таблицу в самой зверской конфигурации, разве что. V>>Но уже полмиллиона средних по тяжести запросов — не умеет. S>Да, увы, MS SQL — не лидер. Лидер — Oracle. Они делают 30 миллионов транзакций в минуту.
Это пол-миллиона в секунду?
Это аккурат уровень MS SQL, PostrgeSQL и MySQL.
Все они последние примерно 5 лет идут ноздря в ноздрю.
По мере улучшения надёжности MySQL он постепенно перестал вырываться сильно вперёд перед "тяжелыми" лидерами, да и те подтянулись и упёрлись.
Усё.
V>>В случае биржи нужно в рамках одной транзакции обновить данные в двух таблицах и добавить строчку/строчки в еще две. V>>И при этом выполнять агрегацию на регистрах и одновременно выполнять в несколько раз больше запросов на чтение, чем транзакций. S>Да, TPC-Cшные транзакции тоже засчитывают только модификации. Одновременно с которыми нужно выполнять в несколько раз больше запросов на чтение. Подробности можно прочитать здесь: http://www.tpc.org/TPC_Documents_Current_Versions/pdf/tpc-c_v5.11.0.pdf, раздел 2.
Это типа ты привёл цифры от одного теста, а даёшь спецификации другого?
Забавно.
V>>Скажи — а какой смысл вообще разгребать такой трафик глупого SQL на ровном месте и каждый божий раз как с 0-ля разбираться с каждым из миллиарда типовых запросов? V>>За что именно ты сейчас борешься? )) S>За здравый смысл и взвешенный выбор.
Мой здравый смысл подсказывает, что трафик, близкий к максимальному, не будет слишком разнообразным.
Что чем выше разнообразие, тем меньше трафик этого "разнообразного".
Это классика жанра — я же не вылизываю в программе "однократные" вещи?
Зато вылизываю "critical path", который выполняется в цикле бесчисленное мн-во раз.
V>>В тестах SQL, вовлечено намного меньше. V>>Обычно моделируется движение по банковским счетам, а эта операция примерно втрое проще, чем сделка на бирже. S>Обычно моделируется движение товара, а эта операция примерно в десять раз сложнее, чем сделка на бирже.
Громче надо глупости говорить, еще громче.
Я ж приводил выше две модели движения товара — партионный учёт и средневзвешенный.
Партионный учёт — это в точности то, что происходит на бирже, с точностью до мелочей.
Ценные бумаги — такой же товар.
А средневзвешенный учёт по складам в точности равен движению денег по счетам в плане трудоёмкости операций, т.е. проще раза в три (по моему личному опыту и виденным системам).
S>>>И что от "SQL безнадёжно устарел" мы переходим V>>Не переходим, безнадёжно устарел. S>Я его венцом творения не считаю. Но ты совершенно не понимаешь природу его недостатков, и критикуешь несущественные вещи.
И бью в самую точку, показывая глупость нынешней схемы, пусть она даже сложилась по "серьёзным историческим причинам".
Ну, ОК, пусть схема не глупа, тут глупым является то, что эта схема не "одна из", которая применялась бы для каких-то весьма специфических сценариев (где я применяю скрипты, например), а единственная.
S>Никакой аналог SQL не сделает его более пригодным для скоростной торговли на бирже.
Какие громкие слова-то.
А ведь используются "аналоги".
Просто компиллируемые.
В системах попроще — в p-Код.
В посложнее — в нейтив.
IBM все годы активно скупала производителей движков БД и прочие наработки из разряда "БД как библиотека".
Ты еще не забыл, что современный сервер приложений часто от БД отделён, что лишнее звено даёт лишнюю латентность?
А клиент-серверные системы и вовсе кошмар, потому что язык программирования серверной части БД ужасен, опять же по историческим причинам.
И язык, и способ хранения и исполнения "команд" и вообще все сценарии, которые вокруг этого способа возникают.
S>А то, что подходит для биржи, не будет подходить для современных учётных и банковских приложений.
При том, что характер операций идентичный.
Че-та ору сегодня.
V>>Преимущество его сейчас в его распространённости. S>Преимущество — в существенной независимости клиента от сервера.
Так тебе веб-сервисы не нравятся, что ле?
Ну или любые другие АПИ для удалённого доступа к некоей функциональности?
S>В типичной ентерпрайз системе образца 90х-2000х — пара тысяч хранимых процедур.
У меня больше было, под 5 тыс, и?
Да и сейчас, в обычной программе "процедур" вряд ли меньше, может даже сильно больше, и?
Хотя не, чтобы описать на нормальном языке тот же функционал понадобилось бы меньше процедур, ес-но, и объем кода сократился бы раз в 100.
Просто сам язык — г-но.
Вокруг похожих сценариев но над разными таблицами — россыпь самостоятельных процедур.
Тела многих из них практически идентичны.
По крайней мере слишком похожи, отличаются в мелочах.
А такие признаки — это признаки убогого инструмента, а не аргумент в его пользу.
Это как в Дельфи каждую коллекцию ручками с 0-ля писать... Бррр...
S>Каждая — для какого-то сценария. Не три типа "заранее известных" запросов, а две тысячи! Заниматься их ручной оптимизацией в компайл-тайме — безумие.
Безумие думать, что твои две тысячи процедур настолько уникальны.
Там функциональности — с гулькин нос.
А объем кода, трудоёмкость разработки и сопровождения — ЧУДОВИЩНЫЕ.
Позорище это всё, кароч. Просто позорище как есть.
Надувать с важным видом губу "а вы знаете что там, у-у-у" — подставляться под иронию.
Знаю слишком хорошо.
В том числе хорошо понимаю причины всех этих нелицеприятных "у-у-у". ))
V>>А когда вообще люди начнут отвыкать от того, что "база данных всегда тормозит" и вздохнут спокойно? S>Когда появятся нормальные приложения. База данных обычно летает как трофейный мессершмит, если не навешивать над ней убогие ORM-системы.
Мде? А НС и Ко (включая основной его ник) на этом же сайте регулярно доказывают, что ORM летает как трофейный мессершмит, что все эти затраты "не видны и под микроскопом при обращении к базе".
Вы уж определитесь там. ))
S>Когда мне тут рассказывают, что миллион строк — это бигдата, я смеюсь.
Покажи этот рассказ, посмеемся вместе?
Не сможешь?
Не сможешь.
Потому что опять для красного словца, как каждое второе предложение в этом посте.
Ты реально наподзалетал в одном только этом сообщении на минимум полтора месяца неотсвечивания.
Ну это если совесть есть и самоуважение.
Re[20]: В России опять напишут новый объектно-ориентированны
Здравствуйте, _ABC_, Вы писали:
_AB>Полдня работы по переписыванию с С# рибара на SQL — время работы сократилось до 5 минут. Плюс пара новых индексов — время работы сократилось до 30 _AB>секунд. Т.к. это часть ночного пакета, дальше оптимизировать смысла не имеет, оставил так. _AB>Наверное, некоторые из тех разработчиков тоже рассказывают про то, что SQL устарел и надо переходить на другие инструменты. _AB>Ну, или рассказывали.
А что ты знаешь о реляционной алгебре?
А если бы ты описал эти же операции языком реляционной алгебры?
А с чего ты решил, что "некоторые из тех разработчиков" что-то вообще говорили против SQL, а не попали в популярную ситуацию, когда на небольшом кол-ве данных алгоритм работает хорошо, но уже на миллионе нет?
И с чего ты решил, что те же самые программисты, наблюдая работу алгоритма над миллионом строк, сделали бы его конечный вариант хуже, чем ты?
И с чего ты решил, что на их месте в момент разработки ты бы сделал лучше?
=============
И как вообще можно было породить такой пост, который можно бесконечно засыпать встречными вопросами?
Ты хоть читаешь перед отправкой? ))
Здравствуйте, Terix, Вы писали:
F>>короче, это плохо, потому что тебе не нравится. твоя позиция понятна. T>А твоя позиция — это хорошо, потому что нравится тебе.
у меня нет позиции. я спрашиваю.
T>У тебя был аргумент — почему не добавить к объекту методы, которые реализуют логику, которая ему принадлежит. Мой — сущности, которые ты вытаскиваешь из БД объектами не являются, поэтому твой аргумент тут не применим.
из БД я вытаскиваю разные вещи. в зависимости от того, как я работаю с базой.
это могут быть наборы полей, это могут быть цельные сущности или что-то ещё. это всё можно смапить на какие-то объекты с логикой.
...coding for chaos...
Re[22]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Так-то я тоже в своё время отпахал на Обязательных Работах: чинил хранимки, написанные индусами. Типичное ускорение после починки — 50х. S>Чуваки, которые пришли в SQL из клиппера (это я предполагаю), ухитрялись простейшие вещи делать вложенными курсорами.
А может всё проще?
Может, им просто было удобней императивно?
А если бы у них был инструмент реляционной алгебры в явном виде, может и не нужны были бы курсоры?
Расписали бы себе в любимом императивном виде и ву-а-ля, ы? ))
Ведь императивная последовательность операций РА сама по себе является эдаким "уравнением", которым можно вертеть как угодно, применяя преобразования, сохраняющие тождественность. Т.е. операции из реляционной алгебры приводимы к операциям реляционного исчисления и наоборот.
Не думал еще в эту сторону?
Как из таблицы b удалить записи, встречающиеся в таблице a?
Здравствуйте, vdimas, Вы писали:
V>Ничего сложного мы пока не обсуждали.
Ктож виноват что ты на азах сломался.
V>Говорит о непонимании тобой причин этого, не?
Не, это говорит о твоем не желании разобраться как оно на самом деле устроено, и почему именно так.
V>Ты себе граф обхода вариантов при построении плана запросов нарисовал бы разок, коллега, и устыдился.
Ты хоть бы в кэш планов реальной базы посмотрел бы разок и устыдился. Потом поговорим про "использование частей планов в разных запросах".
Мы уже победили, просто это еще не так заметно...
Re[14]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>Нет. Это проблема — именно ORM. Потому что без ORM мы на тех же языках работаем с рекордсетами, которые не требуют порождать по классу на запрос. И прекрасно биндим их хоть в UI, хоть в бизнес-логику. S>ORM претендуют на какую-то помощь, которой по факту не оказывают.
Ну если ты считаешь, что на запросы, которые по смыслу дают результаты одного типа не надо отводить класс, то ORM и правда будет тебе частично мешать. Мне подход с отдельными классами симпатичен.
S>Напомню, что в обычном приложении до-ORMной эпохи нет никаких Eager Load — мы просто выполняем запрос и получаем результат.
Я выступаю за то, чтобы использовать ORM в этом же духе. Плюс один и тот же запрос мы можешь сделать с lazy или с eager — удобно.
S>Ну, 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 ? S>И всё это дружелюбно к кэшу и всё такое? S>Я на него много лет не смотрел
Это и sql-92 не поддерживает. Но вообще как-то так Hibernate может.
S>Требование "знать заранее" напоминает мне старую сказку про порошок от блох — который надо сыпать в глаза каждой блохе.
Ну тут не денешься никуда. C SQL надо знать заранее и с ORM надо знать.
S>Автоматический инструмент должен решать проблемы, а не создавать их. Требование вручную размечать код для устранения боттлнеков противоречит самой идее абстрагирования
Я считаю, что ORM решает проблему построения типовых запросов и преобразования их результатов в структуры. Плюс немного решает ситуации где полезен кеш. И всё.
S>Так проблема-то в том, что полноценные ORM вообще никакого решения для этого случая не предлагают.
Предлагают написать запрос на внутреннем языке ORM. То есть заюзать вариант SQL.
S>Нет. Теперь надо понимать не только нутрянку БД, но ещё и нутрянку ORM. Ящетаю — в баню таких "помощников".
Тогда тебе надо будет знать нутрянку БД и нутрянку кода приложения для связи с БД.
S>Если я захочу засунуть логику в SQL, то я обойдусь средствами SQL, а ORM выкину на помойку, т.к. он мне вообще не помогает.
Помогает с типовыми запросами и маппингом в объекты
Re[20]: В России опять напишут новый объектно-ориентированны
S>>Ок, Nasdaq молодцы, могут до примерно 2х с копейками миллионов транзакций в секунду. V>Биржевых транзакций.
Отож.
V>Я сразу давал свои оценки в диапазоне 1-2 порядка. V>Как раз полтора порядка ближе всего к истине.
2 раза. S>>Да, увы, MS SQL — не лидер. Лидер — Oracle. Они делают 30 миллионов транзакций в минуту.
V>Это пол-миллиона в секунду? V>Это аккурат уровень MS SQL, PostrgeSQL и MySQL. V>Все они последние примерно 5 лет идут ноздря в ноздрю.
Нет. На MS SQL никто пока не смог воспроизвести этот результат.
V>По мере улучшения надёжности MySQL он постепенно перестал вырываться сильно вперёд перед "тяжелыми" лидерами, да и те подтянулись и упёрлись.
Шутку понял. Смешно. Такая нагрузка MySQL может только присниться в эротическом сне.
V>>>В случае биржи нужно в рамках одной транзакции обновить данные в двух таблицах и добавить строчку/строчки в еще две. V>>>И при этом выполнять агрегацию на регистрах и одновременно выполнять в несколько раз больше запросов на чтение, чем транзакций. S>>Да, TPC-Cшные транзакции тоже засчитывают только модификации. Одновременно с которыми нужно выполнять в несколько раз больше запросов на чтение. Подробности можно прочитать здесь: http://www.tpc.org/TPC_Documents_Current_Versions/pdf/tpc-c_v5.11.0.pdf, раздел 2.
V>Это типа ты привёл цифры от одного теста, а даёшь спецификации другого?
Нет. Цифры — от того же теста. 30 249 688 транзакций TPC-C в минуту.
V>Мой здравый смысл подсказывает, что трафик, близкий к максимальному, не будет слишком разнообразным. V>Что чем выше разнообразие, тем меньше трафик этого "разнообразного".
Откуда дровишки? Я вот в природе очень редко встречаю "резкие" распределения. Куда ни ткни — лидер занимает вовсе не 80%, а от силы 15%.
А всё остальное размазано ровным слоем по бутерброду.
То есть у нас, допустим, есть 2000 операций (а у людей — и 8000), и вполне себе все выполняются примерно с одинаковой частотой.
И суммарный трафик — вполне себе заметный. Ну, не 30 миллионов транзакций в минуту. Но миллион транзакций в сутки всё же есть. То есть совсем уж говно использовать нельзя, но и боттлнек — не в парсинге запроса.
V>Я ж приводил выше две модели движения товара — партионный учёт и средневзвешенный. V>Партионный учёт — это в точности то, что происходит на бирже, с точностью до мелочей. V>Ценные бумаги — такой же товар.
V>А средневзвешенный учёт по складам в точности равен движению денег по счетам в плане трудоёмкости операций, т.е. проще раза в три (по моему личному опыту и виденным системам).
Всё же стоило бы открыть спецификацию TPC-C и посмотреть, что именно там называют транзакцией.
V>И бью в самую точку, показывая глупость нынешней схемы, пусть она даже сложилась по "серьёзным историческим причинам". по ссылке очередное беспредметное умничание про номера поколений языков.
V>Ну, ОК, пусть схема не глупа, тут глупым является то, что эта схема не "одна из", которая применялась бы для каких-то весьма специфических сценариев (где я применяю скрипты, например), а единственная.
Ну почему же единственная. Вон, NASDAQ как-то обходится без неё.
V>Просто компиллируемые.
Это не аналог. V>При том, что характер операций идентичный.
Ну где же он там идентичный. На бирже что, реально выставлены 8000 операций в протокол клиента? V>Так тебе веб-сервисы не нравятся, что ле?
Нравятся. Но мы же говорим об SQL.
V>У меня больше было, под 5 тыс, и?
И как это укладывается в схему "статической компиляции" и выбора планов запросов? V>Хотя не, чтобы описать на нормальном языке тот же функционал понадобилось бы меньше процедур, ес-но, и объем кода сократился бы раз в 100.
Объём — да. Количество "процедур" скорее всего бы только возросло.
V>Вокруг похожих сценариев но над разными таблицами — россыпь самостоятельных процедур.
Ну вот, начинается осознание реальных проблем SQL. Отсутствие средств по декомпозиции, к примеру.
Это как бы вообще ортогонально способу компиляции — статическому или динамическому.
V>Мде? А НС и Ко (включая основной его ник) на этом же сайте регулярно доказывают, что ORM летает как трофейный мессершмит, что все эти затраты "не видны и под микроскопом при обращении к базе".
Он имеет в виду другие ОРМ, чем я тут упомянул.
V>Потому что опять для красного словца, как каждое второе предложение в этом посте.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Terix, Вы писали:
V>>Не выходит, это ты только что так сам решил. V>>Кто это может мне запретить оперировать непосредственно "протокольными" типами данных? )) T>Запретить тебе мало что можно. Можно даже написать весь код не используя структур и внутри main.
Структуры уже есть.
))
T>Но так не делают. То же самое с использованием объектов, которые получаются из базы.
Из базы получаются данные.
А то, что в ООП-языках структуры данных описываются с помощью таких же механизмов ООП (включая инкапсуляцию) — да забей. ))
T>Только речь не о протокольных типах данных, а об отображении таблиц БД на структуры. Почему логику туда не надо класть я уже писал, думаю, ты со мной согласен.
Вот давай, не торопясь, отделяя мух от котлет, попробуй снова.
Я когда-то в конце 90-х прошёл похожую стадию отделения "объектов" как активных сущностей от объектов как "просто типов данных" (или простых контейнеров оных).
Но ощущения еще помню, могу скорректировать размытые места в рассуждениях, если захочешь.
Например, некоторые на этом сайте в погоне за чистотой понятий требуют от "просто типов данных" (ADT) слишком многого и, мол, если в эти ограничения не влезло, то это не ADT.
Но это еще и не объект.
И вообще, какое кому дело? Мы орудуем в рамках инструмента наиболее пригодным в этих рамках образом.
Поэтому, не любой пользовательский класс описывает "объект".
Если этот класс лишь инкапуслирует свои поля, и всё "поведение" его заключается в методах-хелперах по набитию себя данными и валидации их — это не объект нифига.
T>А насчёт использования в приложении — если ты это делашь — ты завязываешь бизнес логику на логику хранения данных, а это нехорошо.
Это кто тебе такое наврал? ))
Твоя программа — это модель некоего (обычно динамического) процесса.
Разумеется, различные части этой модели должны быть хорошо сопряжены м/у собой или такую модель надо отправлять на доработку.
V>>Хотя, справедливости ради, у себя в С++ мы их заворачиваем в удобные обертки для доступа и манипулирования содержимым. T>Можно кусок кода? Я лучше пойму, что ты имеешь в виду.
class SomeThing {
public:
....
void setSomeProp(int value) {
checkValueRangeForSomeProrOfSomeThing(value);
body_->some_prop = value;
}
void someProp(int value) const {
return body_->some_prop;
}
void setMode(SomeEnum mode) {
switch(mode) {
...
// initialize and validate a bunch of fields according to mode
}
}
private:
struct xyz_some_thing_t * body_;
};
V>>А как много логики ты кладёшь в аргументы и возвращаемые результаты ф-ий? V>>Наверно, логики кладёшь не много, но используешь эти типы данных в логике широко. T>Логики немного, да, и использовать эти данные в логике не очень правильно. Но я тут хочу вернуться к тому, что штука, про которую ты говоришь — ORM и есть.
Тебя название смущает?
С т.з. языка С++ я только что описал объект.
С т.з. дизайна программы — структуру данных.
Re[23]: В России опять напишут новый объектно-ориентированны
Здравствуйте, vdimas, Вы писали:
V>А может всё проще? V>Может, им просто было удобней императивно?
Конечно. Потому что из курса когнитивной психологии мы знаем, что удобно == привычно.
Как всю жизнь пользовались курсорами, так и тут будем.
V>А если бы у них был инструмент реляционной алгебры в явном виде, может и не нужны были бы курсоры?
У них был инструмент реляционной алгебры. Называется SQL. V>Расписали бы себе в любимом императивном виде и ву-а-ля, ы? ))
V>Ведь императивная последовательность операций РА сама по себе является эдаким "уравнением", которым можно вертеть как угодно, применяя преобразования, сохраняющие тождественность. Т.е. операции из реляционной алгебры приводимы к операциям реляционного исчисления и наоборот. V>Не думал еще в эту сторону?
V>Как из таблицы b удалить записи, встречающиеся в таблице a? V>
V>tmp = a & b;
V>b = b - tmp;
V>
V>Тут любой индус справится без ошибок. ))
Ну почему-то же индусу не писалось delete from a where a.id in (select id from b). Вряд ли он станет задуряться с вот этим вот императивом. Когда можно просто бежать по табличке b курсором и делать if exists(select * from a where id = @id) then delete from a where id = @id. Всегда так делал и теперь буду.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[17]: В России опять напишут новый объектно-ориентированны
Здравствуйте, vdimas, Вы писали:
V>Я высказался однозначно, т.е. однозначными терминами из IT.
Нет, ты лил воду и юлил, на что тебе указали несколько людей. Поступить по мужски ты не в состоянии, вот и ведешь себя как ребенок — врешь и пытаешься выкрутиться, выглядит жалко.
V>Как по мне, похоже на ведение беседы не приходя в сознание.
Ты пишешь странные вещи, мне не понятные, я пытаюсь уточнить, ты видимо осознав, что написал чушь, начинаешь сьезжать с конкретных вопросов — вот как оно на самом деле, а не как по тебе.
MTD>>А ты стал юлить и выкручиваться, что странно, если ты понимаешь о чем говоришь.
V>Еще и нечистоплотен.
Ты еще и нечистоплотен? Это конечно через монитор не понятно, но ок.
MTD>>Где? Вопрос не тупой, вот на что он был задан: MTD>>
V>>>В итоге — готовность работать с современными гигабитными сетками.
V>>>Мейнстримовые БД с такими сетками работать де-факто не готовы.
V>Верно, это тупость. V>Речь шла о скорости передачи данных, а ты упомянул про накопленные их размеры.
А зачем ты тогда написал микросекунды? Или ты не знаешь, что такое латенси, а что такое трупут?
V>А тот факт, что одно переводится в другое через время — игноришь в течении всего обсуждения.
Что во что? Выражайся конкретно, не юли — выглядит глупо.
MTD>>Как ты юлишь и выкручиваешься как щенок нашкодивший доставляет.
V>Это можно было вообразить себе разве что не понимая и половины слов.
Ты же на вопросы не отвечаешь, уточнить не хочешь. Может ты что и понимаешь, но тогда с выражением мыслей у тебя все плохо. Или, что веротнее, ни чего не знаешь — нахватался по вершкам, но умничать охота.
V>>>Ты не работаешь, ты динамишь работодателя. MTD>>Ну так то работодателю видней, а не ноунейму из провинции.
V>С какой радости ему видней? V>Смешно такое втирать на форуме программистов. ))
Кодеры свято верят, что платят за знание крякозябр и как эти крякозябры правильно выстроить, причем другой кодерок может быть люто против таких выстроений имея свое истинно верное мнение. Разработчики же понимают, что платят за решение практических проблем, сферический код в вакууме никому кроме его создателя не нужен.
V>Сие зависит исключительно от глубины владения работодателем техническими деталями. V>Зато любому коллеге не трудно понять ситуацию при беглом взгляде на код — конечно динамишь.
Ой, да ладно, покажи свой код и тут же такой как ты начнет кричать, что код — дерьмо.
V>Тю. За 6 лет можно научиться подробностям предметной области, особенностям языка и т.д., но невозможно кардинально поменять мыслительный аппарат. Особенно после возраста ~25-27-ми лет. Увы.
Хорошо, что с твоим мыслительным аппаратом не так? Почему ты несмотря на возраст выглядишь джуном? Где твои достижения? Что у тебя за душой кроме детского самомнения есть?
V>Показанная мной логическая ошибка в коде никак не была связана с тонкостями языка или еще чем-то таким (в отличие от перегрузки конструктора thread, что не принципиально, разумеется). Но такие очевидные ошибки логики находят студенты-первокурсники, которые только учатся программированию. А кто не находит, тому лучше сменить специальность.
Ты вообще написал про код чушь, не поняв что он делает, даже UB мифическое приплел, на вопрос уточнить как обычно слился. Хотя код, да, дерьмо.
V>Потому что программирование — это специфический вид деятельности.
И? Где твои достижения? Строение мозга не позволило?
V>Мыслительный процесс нормального программиста в режиме сосредоточения его на работе напоминает эдакий пульсар
Да, балаболить у тебя отлично получается
MTD>>Посмотри пожалуйста мой актульный код и дай комментарии.
V>Понравилось? ))
Нет, ты даже не понял, что код делает. Но вдруг в следующий раз у тебя получится лучше. Попробуй, хотя крайне маловероятно, конечно.
Чуть, не забыл — ставь минусики и смайлики, глядишь попустит.
Re[24]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
V>>Может, им просто было удобней императивно? S>Конечно. Потому что из курса когнитивной психологии мы знаем, что удобно == привычно. S>Как всю жизнь пользовались курсорами, так и тут будем.
Императивно != курсоры.
Императивно можно и над множествами.
V>>Тут любой индус справится без ошибок. )) S>Ну почему-то же индусу не писалось delete from a where a.id in (select id from b).
Думаю, ты малость преувеличиваешь, даже "индусы" (как явление) на императивщину скатываются в чуть более сложных сценариях.
Сложных с т.ч. реляционного исчисления, а в терминах реляционной алгебры они всё еще примитивны.
S>Вряд ли он станет задуряться с вот этим вот императивом. Когда можно просто бежать по табличке b курсором и делать if exists(select * from a where id = @id) then delete from a where id = @id. Всегда так делал и теперь буду.
Мой вариант с РА самый простой.
Большинство именно манипуляций в РА расписать проще, чем через РИ.
Через РИ зато проще описывать выборки.
В идеале эти два инструмента должны работать совместно.
Ну и, РА оперирует типами, а SQL и вообще современные БД — доменами.
Алгоритмы привязываются к экземплярам таблиц, а не к их схемам.
Собсно, в последних версиях того же MS TSQL уже более-менее продвинулись к нужной схеме (возврат таблиц из ф-ий и подача таблиц как аргументов ф-иям), но пока слишком зачаточно это всё и MS-specific.
F>на практике получается так: F>1. давайте заюзаем новую мегафичу из XZSQL. я прочитал на выходных в релиз нотесах
Вот с этого момента надо желающих отправлять в отдельную ветку репозитория и нехай там поварятся. Дать им чуть времени, потом потребовать результата. При успехе выдать пермию.
Matrix has you...
Re[19]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
S>А механизмы экономии на парсинге и построении плана уже известны — понятие "prepared statement" существует во всех ведущих СУБД уже лет 30 как.
Как и JIT в дотнете. И всё-равно сливает в среднем в 3-5 раз нейтиву в простых сценариях и на порядок в более-менее сложных.
Потому что дело не только в JIT, хотя и в нём тоже.
Круги по воде от выбора динамики vs статики идут слишком далеко, влияя чуть ли не каждый аспект происходящего, меняя его до неузнаваемости.
Современный динамический выполнитель запроса после SQL — он "унутре" построен на аналогах PropertyDescriptor и ExpressionTree, давая на каждую минимальную операцию чтения/записи поля многократный оверхед, акурат как в любом скриптовом движке. И это прямо в ядре БД.
Кое-что пытается оптимизироваться, но выходит не ахти. Припиши к числу слагаемое "+0" в теле запроса и скорость выполнения запроса может измениться многократно. Кароч, неустойчивость характеристик. А где неустойчивость, там начинается шаманство и эзотерика. А стоит воскликнуть "король-то голый", так шикать начинают. )))
Аналогично с пользовательскими ф-иями, писанными на SQL — классика скриптинга в плане эффективности.
Re[19]: В России опять напишут новый объектно-ориентированны
Здравствуйте, Sinclair, Вы писали:
C>>Для полумилииона транзакций в SQL нужны очень специальные условия. То есть, минимум join'ов (если вообще), sharding таблиц по какому-то признаку или небольшой объём данных (чтоб всё в памяти было). При этом оно будет в любом случае с кластером и облаком админов для шаманства вокруг него. S>Это мировой рекорд в TPC-C. Там количество joinов и объём данных регламентированы условиями теста. И транзакции запрещено "коммитить" в памяти.
Ну да, со стоимостью в $1 за транзакцию в минуту. Супердёшево.
То что коммитить в памяти нельзя — это не проблема, просто достаточно писать линейно в журнал и при запуске проигрывать его поверх копии данных в памяти. Тем более, что объёмы данных в TPC-C совершенно детские по нынешним меркам.
Если делать честные join'ы, с чтением данных с дисков, то произвольный SQL не работает ну никак. Оно умрёт или на пропускной способности хранилища, или на пропускной способности между узлами кластера.
Или, например, есть табличка в пару петабайт — на нескольких тысячах узлов. Там в принципе не особо много чего живёт, кроме map-reduce'а со специально написанными алгоритмами.
Клиппер был приведён специально, разумеется.
Далее по списку полно современных вкусностей.
А ты опять показал себя, как бэ это помягче, далёким от вопроса. ))
На момент выхода dBase II (прообраз Клиппера) еще не было SQL-серверов в их сегодняшнем традиционном понимании.
Оракл на тот момент представлял из себя примерно то же, что и dBase II.
Более-менее нормальной SQL-базой в современном понимании Оракл стал в 1992-м году в 7-й его версии.
Учите матчать кароч.
Даже глупый FirebirdSQL, для сравнения, многократно лучше Oracle 6, который был в ходу до 92-го года.
==============
В принципе, о "нормальных" SQL-серваках стало можно говорить лишь во второй половине 90-х, и вот уже в конце нулевых начинается их заметный закат. Итого, жалкие 15 лет жизни. Временщики... ))
Временно заткнули образовавшийся вакуум и уходят в сторону.
Трындёжь тут рядом про "последние 30 лет" — он от невежества в сочетании с надуванием губ в попытке приписывания себе чужих успехов.
Здравствуйте, Sheridan, Вы писали:
F>>на практике получается так: F>>1. давайте заюзаем новую мегафичу из XZSQL. я прочитал на выходных в релиз нотесах S>Вот с этого момента надо желающих отправлять в отдельную ветку репозитория и нехай там поварятся.
а работу за них кто будет делать?
S>Дать им чуть времени, потом потребовать результата. При успехе выдать пермию.
Здравствуйте, Sinclair, Вы писали:
V>>Есть языки и/или расширения к имеющимся (к С++, например), которые переводят второе в первое. V>>То бишь, параллелят, если данные уже в памяти. S>Ничего не получится. На всякий случай напомню, что речь — про lazy load, и невинная итерация по коллекции orders скрывает за собой возможный раундтрип до СУБД.
Сосредоточься. Я говорил о компиллируемом коде на стороне БД.
V>>Ну, начнём с того, что постановка вопроса "удобства" во главу угла является ошибкой, бо это не первопричина, а следствие. Это удобство сегодня требуется из-за тотального разрыва в стеке технологий в случае "обычного SQL" и является лишь способом адаптации разработчиков к такому разрыву. S>Это как раз первопричина. Нужно понимать, что данные — это факты. Трактовка этих фактов (бизнес-правила) меняются по пять раз в квартал. А вот сами данные остаются теми же самыми. И разрыв в стеке технологий тут совершенно ни при чём.
Весёлый ты. ))
"Ребята, нужно понимать, что береза — это дерево. А листья сбрасываются раз в год. Поэтому, снегири тут не при чём."
Умудрился дважды сам себе противоречить в одной фразе.
"данные остаются теми же"
"меняется код"
"но разрыв технологий не при чём"
При том что именно разрыв технологий делает каждое изменение логики чудовищно дорогим.
Стоимость изменения пары строк в БД сегодня равна стоимости изменения десятков тыщ строк на "обычном ЯП".
Т.е. твой разрыв технологий, который "не при чём", делает развитие базы совершенно неприличным по стоимости и тормознутости занятием.
Развитие кода БД медленное, реакция на изменения бизнес-логики страшно не оперативная, фактически ступор, по сегодняшним реалиям.
S>Разрыв в стеке технологий — это то, что сам SQL спроектирован плохо. Он же был рассчитан на одноразовые интерактивные запросы. Там почти что нет возможностей по декомпозиции
Да, SQL был придуман ровно тогда, когда придумывали командные языки консоли, типа REXX или взять историю современного Bash.
SQL был таким же "консольным" языком изначально.
Делать же "взрослый" язык из "консольного" чуть позже... Ну ты понял.
Пусть даже TSQL имеет и ф-ии и типы данных, а PL/SQL местами даже прекрасен, но они имеют в базе какашку.
S>из-за чего на нём невозможно писать мало-мальски сложную логику.
Т.е. из-за одного и того же косяка большего кол-ва языков 4-го поколения, а именно — исторически SQL был разработан как язык для непрофессионалов в области реляционной алгебры или реляционных исчислений. Он должен был быть приближен к обычному английскому.
Поэтому, о формальной строгости языка речи быть не могло.
Этот язык — просто набор неких "фраз".
Вот и выходит, что де-факто SQL всё-равно пользуют лишь специалисты. Но плюются от тех косяков, которые были заложены из-за ориентации не на них. ))
S>Потому-то создатели ентерпрайз-приложений и сбежали из хранимок в яву — то есть от клиент-сервера к трёхзвенке. После ужасов тридцатистраничных хранимок даже ява с её бесконечными factory bean кажется глотком свежего воздуха.
Ага, понимаешь проблематику?
А как ты тогда умудрился привести обновляемость (наверно, имелась ввиду скорость и стоимость такого обновления?) как аргумент в пользу SQL?
Де-факто всё с точностью до наоборот.
Грубо можно посмотреть на 1C — насколько мала трудоёмкость внесения туда изменений и как оперативно можно делать такие изменения в сравнении с "традиционной" схемой, когда ты реализуешь логику в базе, на серваке (приложений) и клиенте. ))
Здравствуйте, Terix, Вы писали:
T>У тебя был аргумент — почему не добавить к объекту методы, которые реализуют логику, которая ему принадлежит. Мой — сущности, которые ты вытаскиваешь из БД объектами не являются, поэтому твой аргумент тут не применим.
А сущность "заказ" — это тоже "объект"?
Или просто данные, а объектом можно сделать некую другую сущность "менеджер заказов", который умеет управлять их состоянием?
Т.е. почему бы не построить модель происходящего, приближенную к реальной?
Вот "заказ" — это ж мёртвая бумага, носитель.
"Менеджер" — живой человек, он берёт заказ и что-то с ним делает.
"Склад" представлен работниками склада, которые совершают движения ТМЦ согласно "накладных".
Опять же "накладная — это просто инфа на неживом носителе.
Запись в реестре ТМЦ (регистры) — это тоже неодушевлённые сущности, просто инфа на мёртвом носителе.
Но "кладовщик" внесёт туда поправки — скорректирует регистры по изменившимся в кол-ве ТМЦ.
И т.д.
Здравствуйте, Terix, Вы писали:
НС>>Логика зато имеет место быть в самих запросах. А вот если ты ее оттуда вынешь, то вот тут уже и огребешь по полной от производительности. T>Чем её меньше в запросах, тем лучше. Но попадает периодически, это правда, никуда не денешься.
Странные рассуждения.
А чем ты вообще руководствуешься в дизайне?
Критерии какие?
И почему ты игноришь один из самых главных критериев через, секундочку, "но никуда не денешься".
Это какой такой критерий смог переплюнуть один из самых главных?
Кароч, колись! ))
Откуда ты этих догм понабрался, дай мне адрес сего рассадника, ворвусь туда и сожгу там всё нафик...
Мы уже победили, просто это еще не так заметно...
