Re: Проблемы современных СУБД
От: vsb Казахстан  
Дата: 14.02.18 21:37
Оценка:
Здравствуйте, vdimas, Вы писали:

V>Справедливости ради, удобный язык для удалённого доступа к данным напрашивается уже слишком давно.


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


А что в SQL плохо? Или сама концепция реляционной базы данных неудобна? Мне в SQL не нравятся некоторые вещи, но это чисто на уровне синтаксиса (много зарезервированных слов, неудобно генерировать условия, нельзя писать x == :param для null и тд).
Re[14]: В России опять напишут новый объектно-ориентированны
От: vdimas Россия  
Дата: 14.02.18 21:59
Оценка:
Здравствуйте, Sinclair, Вы писали:

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

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

Это ограничения языков, где "класс" — это что-то занимающее место в релизе.
В компиллируемых языках типы стираются.
Будь хоть миллиард классов — в выходном бинарнике их нет.


S>ORM претендуют на какую-то помощь, которой по факту не оказывают.


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

Но рекордсет тормозит безбожно, дешевле выполнять логику "обычными" объектами, а из рекодрсета просто загружать в них данные.
Отредактировано 14.02.2018 22:00 vdimas . Предыдущая версия .
Re: Проблемы современных СУБД
От: smeeld  
Дата: 14.02.18 22:40
Оценка:
Здравствуйте, vdimas, Вы писали:


V>Справедливости ради, удобный язык для удалённого доступа к данным напрашивается уже слишком давно.


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


Какие-то отвлечённые рассуждения. Тут недавно наваяли SQL базу на python для исполнения в Postgre. Хе, это когда таблицы SQL db описываются python-овыми dict и list, но трансформируются именно в SQL базу при создании базы. База выведена наружу прямо в чисто python-овые модули демона. В целом прикольно получилось. SQL-кусками, где надо, как константные значения python-овых переменных. Каких-либо ограничений, неудобств, и пр не обнаружено.
Re[21]: В России опять напишут новый объектно-ориентированны
От: _ABC_  
Дата: 14.02.18 22:46
Оценка: -1
Здравствуйте, vdimas, Вы писали:

V>И как вообще можно было породить такой пост, который можно бесконечно засыпать встречными вопросами?

Любой пост можно бесконечно засыпать встречными вопросами.
Один глупец может задать столько вопросов, что не ответит и сотня мудрецов.
Re[21]: В России опять напишут новый объектно-ориентированны
От: vdimas Россия  
Дата: 14.02.18 22:54
Оценка: -4 :)))
Здравствуйте, IB, Вы писали:

V>>Ничего сложного мы пока не обсуждали.

IB>Ктож виноват что ты на азах сломался.

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

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


V>>Говорит о непонимании тобой причин этого, не?

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

Я подробно разбирался с этим задолго до того как ты написал свой первый SQL-запрос, во время того как ты недолго их писал и после того, как ты давно уже перестал этим заниматься. Начистоту если, у тебя ваапще никогда не было возможности ознакомиться с этим моментом так близко, как знакомился я и многие другие коллеги.
Именно поэтому ты каждый раз в подобных обсуждениях ты что-то там вещаешь общими словами, как сейчас.
Зачем ты это каждый раз делаешь? А как же "лицо"?
Ты НЕ ЗНАЕШЬ как оно работает.
Ты не представляешь себе алгоритм составления очередного варианта плана запроса, т.е. алгоритм перебора графа их.
Да ты никогда и не интересовался толком, бо тебе больше нравится роль наблюдателя "черного ящика".
И я не говорю, что это плохая роль.
Это отличная, годная роль, вполне достаточная для успешного пользования технологией...
Только зачем пытаться окружающих поставить на тот же уровень — тут я перестаю понимать.
Вот что тебе с того? Мотив?


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

IB>Ты хоть бы в кэш планов реальной базы посмотрел бы разок и устыдился.

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


IB>Потом поговорим про "использование частей планов в разных запросах".


С тобой не поговорим, ты не в теме целого пласта IT-технологий над графами и задачами поиска решений в ограничениях.
Re[22]: В России опять напишут новый объектно-ориентированны
От: vdimas Россия  
Дата: 14.02.18 23:05
Оценка:
Здравствуйте, _ABC_, Вы писали:

V>>И как вообще можно было породить такой пост, который можно бесконечно засыпать встречными вопросами?

_AB>Любой пост можно бесконечно засыпать встречными вопросами.

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


_AB>Один глупец может задать столько вопросов, что не ответит и сотня мудрецов.


А один брехло может столько наврать, что потеряет лицо.

Если бы ты был честен с собой, ты бы не формулировал ту историю в духе: "вот там все г-но, один я Д'Артаньян".
И уж тем более не додумывал бы всякую хрень из разряда: "наверно они тоже рассказывают, что SQL устарел".
Смотри как много залётов по банальной логике и откровенной нечистоплотности в одном посте.
Re[3]: Проблемы современных СУБД
От: Ops Россия  
Дата: 14.02.18 23:19
Оценка:
Здравствуйте, vdimas, Вы писали:

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

N>>Люди которые это делают всё-равно некомпетентны.

V>Откуда инфа?


От Шеридана.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[23]: В России опять напишут новый объектно-ориентированны
От: _ABC_  
Дата: 14.02.18 23:23
Оценка: +1 -1
Здравствуйте, vdimas, Вы писали:

V>Дудки.

Не дудки, а факт. Можешь с фактами спорить сколько угодно, но вопросами можно завалить любой пост.

V>А один брехло может столько наврать, что потеряет лицо.

Доверюсь тебе в этом аспекте — ты в этом специалист, тебе виднее.

V>Если бы ты был честен с собой, ты бы не формулировал ту историю в духе: "вот там все г-но, один я Д'Артаньян".

Вообще-то, вся тема тут — это ты, рассказывающий, что там все г-но, один вдимас Д'Артаньян.
Так что к зеркалу обратись для начала.
Re[25]: В России опять напишут новый объектно-ориентированны
От: _ABC_  
Дата: 14.02.18 23:24
Оценка: +2
Здравствуйте, vdimas, Вы писали:
V>Собсно, в последних версиях того же MS TSQL уже более-менее продвинулись к нужной схеме (возврат таблиц из ф-ий
Э-э-э... 18 лет стукнуло уже с тех пор, вроде как.

V>подача таблиц как аргументов ф-иям)

А этому 10 лет стукнуло.
Re[2]: Проблемы современных СУБД
От: Ops Россия  
Дата: 14.02.18 23:28
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>б) "эти ваши мускулепостгресы тормозят"


А они тормозят. Мне постгря не дает написать план, а ее оптимизатор делает совсем фиговый, там пара порядков разницы, в сравнение с возможным — тупо перемножает число записей.
Приходится писать 2 запроса и сводить результаты уже у себя, это ппц.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[5]: Проблемы современных СУБД
От: Sheridan Россия  
Дата: 14.02.18 23:43
Оценка:
Здравствуйте, neFormal, Вы писали:

S>>Вот с этого момента надо желающих отправлять в отдельную ветку репозитория и нехай там поварятся.

F>а работу за них кто будет делать?
v

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

F>а при неудаче?
^

Ну то есть сами, пусть догоняют. Например по вечерам
Matrix has you...
Re[3]: Проблемы современных СУБД
От: Sheridan Россия  
Дата: 14.02.18 23:44
Оценка:
Здравствуйте, Ops, Вы писали:


Ops>А они тормозят. Мне постгря не дает написать план, а ее оптимизатор делает совсем фиговый, там пара порядков разницы, в сравнение с возможным — тупо перемножает число записей.

Ops>Приходится писать 2 запроса и сводить результаты уже у себя, это ппц.
Что за запросы?..
Впрочем это надо пройтись по всему от запроса и индексов до железа...
Matrix has you...
Re[4]: Проблемы современных СУБД
От: Sheridan Россия  
Дата: 14.02.18 23:46
Оценка:
Здравствуйте, Ops, Вы писали:

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

N>>>Люди которые это делают всё-равно некомпетентны.
V>>Откуда инфа?
Ops>От Шеридана.
о0
Matrix has you...
Re[4]: Проблемы современных СУБД
От: Ops Россия  
Дата: 15.02.18 00:09
Оценка:
Здравствуйте, Sheridan, Вы писали:

S>Что за запросы?..

Ну сложные, вроде WITH RECURSIVE...
S>Впрочем это надо пройтись по всему от запроса и индексов до железа...

Железо тут при чем? Речь об EXPLAYN ANALISE VERBOSE
Там явно написано, что она перемножает таблицу саму на себя. А я могу лучше план придумать, но возможности нет.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: Проблемы современных СУБД
От: Ops Россия  
Дата: 15.02.18 00:23
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>А что в SQL плохо? Или сама концепция реляционной базы данных неудобна? Мне в SQL не нравятся некоторые вещи, но это чисто на уровне синтаксиса (много зарезервированных слов, неудобно генерировать условия, нельзя писать x == :param для null и тд).


Мне там не нравится больше, в основном подзапросы и именование для их результатов. Вообще, это все глобальные переменные.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[2]: Проблемы современных СУБД
От: Ops Россия  
Дата: 15.02.18 00:27
Оценка:
Здравствуйте, smeeld, Вы писали:

S>Какие-то отвлечённые рассуждения. Тут недавно наваяли SQL базу на python для исполнения в Postgre. Хе, это когда таблицы SQL db описываются python-овыми dict и list, но трансформируются именно в SQL базу при создании базы. База выведена наружу прямо в чисто python-овые модули демона. В целом прикольно получилось. SQL-кусками, где надо, как константные значения python-овых переменных. Каких-либо ограничений, неудобств, и пр не обнаружено.


Это все кривые ORM. А сделаны они так из-за кривого SQL. Только я вот не знаю, как надо лучше.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re: Проблемы современных СУБД
От: Ops Россия  
Дата: 15.02.18 00:32
Оценка:
Здравствуйте, vdimas, Вы писали:

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


Критикуя — предлагай. Мне SQL тоже не очень, но нужны варианты. Можешь дать хоть концепцию?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Re[21]: В России опять напишут новый объектно-ориентированны
От: vdimas Россия  
Дата: 15.02.18 00:35
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>>>Ок, Nasdaq молодцы, могут до примерно 2х с копейками миллионов транзакций в секунду.

V>>Биржевых транзакций.
S>Отож.

Дык, это не транзация БД.


V>>Я сразу давал свои оценки в диапазоне 1-2 порядка.

V>>Как раз полтора порядка ближе всего к истине.
S>2 раза.

20-30 раз.
Смирись. ))


S>>>Да, увы, MS SQL — не лидер. Лидер — Oracle. Они делают 30 миллионов транзакций в минуту.

V>>Это пол-миллиона в секунду?
V>>Это аккурат уровень MS SQL, PostrgeSQL и MySQL.
V>>Все они последние примерно 5 лет идут ноздря в ноздрю.
S>Нет. На MS SQL никто пока не смог воспроизвести этот результат.

Блин, ну ты же врёшь всё время коллегам.
На кого это рассчитано?

Результат в 30 млн tpmC был показан ораклом на каком-то совершенно дичайшем sun-кластере.
А на сравнимой не кластерной технике (обычные серваки на ксеонах) они все ноздря в нозрю ходят:
Машинка — HP ProLiant DL370 G6
Oracle Database 11g — 631766,00
Microsoft SQL Server 2005 — 661475,00

Оракл традиционно чуть посасывает.
Его на "обычном" железе дрючит даже PostgreSQL.


V>>По мере улучшения надёжности MySQL он постепенно перестал вырываться сильно вперёд перед "тяжелыми" лидерами, да и те подтянулись и упёрлись.

S>Шутку понял. Смешно. Такая нагрузка MySQL может только присниться в эротическом сне.

У-у-у, пошло нубство. ))
Возьми свой ноут, который на батарейках, поставь Оракл, MySQL и сравни.
Для прочистки мозгов, такскать.
Как будешь готов — поищи сравнения по и-нету.

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


V>>Это типа ты привёл цифры от одного теста, а даёшь спецификации другого?

S>Нет. Цифры — от того же теста. 30 249 688 транзакций TPC-C в минуту.

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

V>>Мой здравый смысл подсказывает, что трафик, близкий к максимальному, не будет слишком разнообразным.

V>>Что чем выше разнообразие, тем меньше трафик этого "разнообразного".
S>Откуда дровишки? Я вот в природе очень редко встречаю "резкие" распределения. Куда ни ткни — лидер занимает вовсе не 80%, а от силы 15%.

Это при малом трафике.
А когда прёт какой-то невменяемый трафик, то выполняются какие-то одни и те же действия.


S>То есть у нас, допустим, есть 2000 операций (а у людей — и 8000), и вполне себе все выполняются примерно с одинаковой частотой.


Опять же брехня. ))


S>И суммарный трафик — вполне себе заметный. Ну, не 30 миллионов транзакций в минуту. Но миллион транзакций в сутки всё же есть.


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


V>>Я ж приводил выше две модели движения товара — партионный учёт и средневзвешенный.

V>>Партионный учёт — это в точности то, что происходит на бирже, с точностью до мелочей.
V>>Ценные бумаги — такой же товар.

V>>А средневзвешенный учёт по складам в точности равен движению денег по счетам в плане трудоёмкости операций, т.е. проще раза в три (по моему личному опыту и виденным системам).

S>Всё же стоило бы открыть спецификацию TPC-C и посмотреть, что именно там называют транзакцией.

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

The Order-Status business transaction queries the status of a customer's last order. It represents a mid -weight read —
only database transaction with a low frequency of execution and response time requirement to satisfy on -line users.


))

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

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

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

Там вовсе не сложная инфа, было бы желание, как грится.
Освой ты её, не подставлялся бы с "декомпозицией", т.е. хотя бы в этом моменте появится вполне предметный смысл.


V>>Ну, ОК, пусть схема не глупа, тут глупым является то, что эта схема не "одна из", которая применялась бы для каких-то весьма специфических сценариев (где я применяю скрипты, например), а единственная.

S>Ну почему же единственная. Вон, NASDAQ как-то обходится без неё.

Ценники недемократические.
Считай, что для тебя этого нет, как и суперкластера Sun из того бенчмарка.


V>>Просто компиллируемые.

S>Это не аналог.

Аналог. В некоторых языках пошли на хитрость, сумев при почти таком же синтаксисе превратить SQL-запросы в полноценные выражения ФП-подобного языка. Но далее уже идёт строгая типизация и прочие плюшки развитого языка.


V>>Так тебе веб-сервисы не нравятся, что ле?

S>Нравятся. Но мы же говорим об SQL.

Мы говорим об общении с удалённым сервисом.


V>>У меня больше было, под 5 тыс, и?

S>И как это укладывается в схему "статической компиляции" и выбора планов запросов?

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


V>>Хотя не, чтобы описать на нормальном языке тот же функционал понадобилось бы меньше процедур, ес-но, и объем кода сократился бы раз в 100.

S>Объём — да. Количество "процедур" скорее всего бы только возросло.

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

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


V>>Вокруг похожих сценариев но над разными таблицами — россыпь самостоятельных процедур.

S>Ну вот, начинается осознание реальных проблем SQL.

У меня сие "осознание" произошло еще до 97-го года.
Просто это первый раз на моей памяти, когда на эти темы народ соглашается просто поговорить.
Сам такой разговор в году эдак 2005-м был просто невозможен.

В общем, тут декомпозицией не отделаешься, тут дизайн языка с 0-ля менять надо.


S>Это как бы вообще ортогонально способу компиляции — статическому или динамическому.


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


V>>Мде? А НС и Ко (включая основной его ник) на этом же сайте регулярно доказывают, что ORM летает как трофейный мессершмит, что все эти затраты "не видны и под микроскопом при обращении к базе".

S>Он имеет в виду другие ОРМ, чем я тут упомянул.

Ну понятно, это кого надо ноги.
Но тогда заход на новый круг.
Так что не так в Датском Королевстве?
Почему rsdn тормозит? ))
Re[24]: В России опять напишут новый объектно-ориентированны
От: vdimas Россия  
Дата: 15.02.18 00:49
Оценка: +1
Здравствуйте, _ABC_, Вы писали:

V>>Дудки.

_AB>Не дудки, а факт. Можешь с фактами спорить сколько угодно, но вопросами можно завалить любой пост.

Речь шла о вопросах, на которые у тебя нет ответов.
А так-то заваливай сколько хочешь.
Если не врать и не изобретать, то всегда можно "отстреляться".
Re[2]: Проблемы современных СУБД
От: vdimas Россия  
Дата: 15.02.18 00:56
Оценка:
Здравствуйте, vsb, Вы писали:

vsb>А что в SQL плохо? Или сама концепция реляционной базы данных неудобна? Мне в SQL не нравятся некоторые вещи, но это чисто на уровне синтаксиса (много зарезервированных слов, неудобно генерировать условия, нельзя писать x == :param для null и тд).


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

Ты же понимаешь, что математически вот этот предикат абсурден: IS NOT NULL?
(если взять принятый в математике и IT способ аппликации ф-ий/операторов)

Чему равно выражение (NOT NULL)? ))
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.