Gt_>> C>Если у вас приложения обновляются без всякого процесса прямо методом "херак, херак — и в продакшн", то это никакая РСУБД не спасёт.
Gt_>> спасает. у рсубд данные и код полностью интегрированны. в оракле не важно кто накатил ddl, поломанный pl/sql код будет отслежен. и это киллер фича.

DC>Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент.
DC>А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит.

угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.

C>>>И это реально ускорит приложение? Не верю. В большинстве случаев, скорее всего, окажется выгоднее кэшировать данные на клиенте и запускать поиск там локально вместо того, чтобы лезть в БД.
Gt_>>кеш уже есть в субд. делать копию этого же кеша что бы там что-то запускать быстрее не будет.
C>Будет.

не будет

M>>Не согласен. А для кого придумали шардирование, микросервисы, репликацию (если уж совсем край)?

A>А какое это отношение имеет к реализации бизнес логики в хранимым процедурам?

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

M>>Неее, ну если тебе дадут реляционную базу и скажут: "Масштабируй," а вся логика приложения завязана на нее и распилить монолит времени нет, то да (ну, там был у тебя бложек на вордпресс, а завтра тебе нужно из него сделать фейсбук). Но, вообще, у Яндекса вся почта на Postgres работает, если чё.

A>У яндекса почта на хранимых процедурах? Они же пишут, что у них бэкенд на плюсах, и что это им позволило достаточно безболезненно перейти с оракла на постгрес.

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

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

Gt_>угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.

С учетом наличия в оракле library cache так себе фича.

Gt_>угу. а потом ныть что примитивный сайт кушает 1.5GB и что бы просто побровсить нужна машина минимум с 8Gb рам и SSD.

Offtop, конечно, но ты чё правда используешь машину без 8Г памяти?

Впрочем, с современной модой на ноутбуки это понятно.

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

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

То есть весь rsdn знает, что "M" это всегда "Masterspline". Да ты крут!!!
По теме: как масштабируются хранимые процедуры? Где на это можно посмотреть хотя бы одним глазком?

A>>У яндекса почта на хранимых процедурах? Они же пишут, что у них бэкенд на плюсах, и что это им позволило достаточно безболезненно перейти с оракла на постгрес.

M>Понятия не имею, есть ли у них хранимые процедуры, но это сильно оффтопик, потому что не про масштабирование. Смысл в том, что не факт, что масштабировать вообще нужно. Яндексу для почты хватило одного сервера Postgres, а проект довольно крупный (возможно несколько для репликации, но база целиком помещается на одном сервере, насколько я понял).

Один сервер Postgres, ах-ха-ха, очень смешно.

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

A>По теме: как масштабируются хранимые процедуры? Где на это можно посмотреть хотя бы одним глазком?

(достаёт сову и глобус)

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

В тред призывается Sinclair.

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

С>(достаёт сову и глобус)

С>Например хранимка может работать с updatable view, а тот в свою очередь работает с секционированной таблицей, раскиданной по разным шардам на куче sql-серверов.

С>В тред призывается Sinclair.

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

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

A>Это опять-таки все про выборку данных. Никто и ничто не мешает мне подергать туже view с сервера приложений. Вопрос же про то, что вы будете делать, когда ваша процедура упрется в процессор?

Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?

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

С>Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?

Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?

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

Gt_> DC>Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент.
Gt_> DC>А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит.
Gt_> угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.

Которая рушит приложение всё и сразу?

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

С>>Чтобы процедура упёрлась в процессор, надо на ней писать то, что требует процессора. И что же, кто-то подобный код на pl/sql пишет?

A>Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?

Скажите пожалуйста, что у вас такая за бизнес-логика, которая требует лютого количества процессора? Составление и коррекция плана перевозок на 100500 автомобилей?

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

С>Скажите пожалуйста, что у вас такая за бизнес-логика, которая требует лютого количества процессора? Составление и коррекция плана перевозок на 100500 автомобилей?

Да любая задача, которая выходит за рамки перекладывания данных из одной таблички в другую. И почему лютого? Вполне обычного. Напомните, как там сервера субд лицензируются? По ядрам или по сокетам?

Gt_>>угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.

A>С учетом наличия в оракле library cache так себе фича.

ты бредишь. учитывая что смена статуса выбрасывает процедуры из library cache.

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

A>>С учетом наличия в оракле library cache так себе фича.

Gt_>ты бредишь. учитывая что смена статуса выбрасывает процедуры из library cache.

Ага, выбрасывает прямо в тот момент, когда твоя процедура твои петабайты лопатит.

Gt_>> DC>Ну поломалась хранимка. И? Приложу отвалится в самый неподходящий момент.
Gt_>> DC>А ОРМ таки попытается туда что-то записать. И если изменения заключались только в создании колонки, то в большинстве случаев это ничему не повредит.
Gt_>> угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.

DC>Которая рушит приложение всё и сразу?

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

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

Gt_>все или ничего — киллер фича. странно, что такой примитив нужно разжовывать.

Спасибо за ликбез. Только объясни один момент: блокировка сессии -- это все или ничего?

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

Gt_>угу. в большинстве случаев прокатит. но мне кажется этот душок индии все же не отменит киллер фичу интеграции данных и кода pl/sql.
Душок Индии — это как раз "интеграция" PL/SQL.

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

С> Скажите пожалуйста, что у вас такая за бизнес-логика, которая требует лютого количества процессора? Составление и коррекция плана перевозок на 100500 автомобилей?

Скажите, а что это у вас за бизнес такой, что не требует количества процессора? Купи-продай на 2 продажи в год?

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

A>Как всегда определяется исходя из конкретных обстоятельств. Запросом к базе максимально фильтруем данные, в приложении раскладываем их по полочкам (коллекциям) и спокойно с ними работаем. Надо сгенерировать штрих-код, подключаем библиотеку, генерируем, сохраняем обратно в базу.
Отличный пример. То есть мы делаем round-trip между базой и апп сервером только ради того, чтобы вычислить несложную функцию. Не уверен, что это — архитектурно лучший вариант.

A>Надо передать данные по проприетарному протоколу, берем у производителя библиотеку, подключаем, передаем. Как это сделать на бд я тоже представляю, но будет это выглядеть как набор костылей.
Конечно. Не дело СУБД заниматься передачей данных по проприетарным протоколам. Тем более, что это может вносить непредсказуемые задержки во времена исполнения транзакций.

A>Единственный плюс. Но если рассматривать архитектуру всей системы в целом, его даже не стоит принимать во внимание.
Конечно. Отсюда и растут современные заниженные ожидания: железо с начала 2000х ускорилось на порядки, а ентерпрайз системы как прожёвывали заказы по 30 секунд, так и прожёвывают.
Потом оказывается, что общей производительности не хватает, и мы выбиваем бюджет на миграции в NoSQL, который лучше шардится и вообще позволяет делать на 250 машинах то, что при толковом проектировании можно было сделать на одной.

A>Как что? Элементарных вещей в этих языках нет, бери любую возможность из современного языка, и не найдешь ее. Про коллекции я уже говорил, еще нет пространств имен (привет, библиотеки), нет подобия linq to objects (хотя казалось бы, данные же обрабатывем), нет кортежей (и это языки расширения в рсубд), нет вывода типов, нет рефлексии, а следовательно нет и мапперов. Да ничего там нет, кроме временных таблиц, и в результате все проблемы выглядят как гвозди.
А кто вас заставляет писать на T-SQL? Во-первых, мы можем генерировать SQL, решая проблему структуризации кода. Тот же linq2db и есть пример такого генератора, который умеет порождать высокоэффективный SQL удобным для программиста способом. Во-вторых, все современные РСУБД позволяют писать код хранимок на широком наборе языков общего назначения.

A>Вы уж определитесь: "стоит избегать" или "не ограничиваете". Вот есть у вас какой-либо расчет на plsql/tsql. Условно, при закрытии месяца база у вас ложится, потому что этот расчет очень любит процессор. Как будете выходить из положения?
Из моего личного опыта — обычно день-два, потраченных на улучшение "расчёта" окупаются сторицей. То, что там "ложилось", начинает исполняться за 10 секунд. Потому что "ложащийся" расчёт написан на SQL неэффективным образом — множество курсоров, временных таблиц, и прочей наркомании.
"Вытащить" расчёт из базы как правило помогает мало — просто потому, что его производительность упирается в дисковый обмен. (Обычно никто даже не пытается внести в базу вычислительно-интенсивные вещи, типа мандельброта или блокчейна).
Если хранимка прожёвывает гигабайт дисковых данных за полчаса, то не получится её ускорить, заставив сервер приложений тащить этот гигабайт к себе в память.

A>Ну, как бы, не факт. Канал между сервером приложений и сервером субд может быть и быстрее канала между сервером субд и хранилищем данных. Все зависит от конкретных решений.
В таком случае у нас есть простой способ: починить канал между сервером и хранилищем. Техника делать быстрые каналы у нас есть.

A>Так еще со времен перла. А при чем здесь версия регулярки на базе и на клиенте? Что такое вообще версия регулярного выражения?
Смотрите: вот у меня в запросе использовалась регулярка типа "\(d{3,6}\)". Потом требования поменялись, и стала нужна регулярка типа "\(d{2,11}\)".
Обычно именно такие сценарии пугают в случае наличия логики в сервере — потому что в апп-сервере регулярка уже новая, а в базе осталась старая.
Это и есть "версия регулярки".
Так вот — ничто мне не мешает внутри моего кода сервера приложений вставить что-то типа

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(@SpecificRegex) AND type = 'FS', N'FT')
BEGIN
... -- код по заталкиванию кода функции MyRegex23423521212 в базу
END

Теперь можно писать

select * from mytable where dbo.MyRegex23423521212(data)

В имя функции входит hash от regex string, поэтому мы защищены от конфликтов между разными версиями кода, ожидающими разных регекспов.
Всё это, естественно, спрятано под капот, и в прикладном коде мы пишем запрос на linq2db.

A>>>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
S>>Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.

A>А вы приведите сложный. Вы же библиотеку регулярных выражений не на plsql/tsql писали, эта возможность вам любезно предоставлена самим движком субд. Кстати, если бы не было регулярок в движке, как бы выходили из положения?
Вот я вам на пальцах объяснил, как добавить поддержку регулярок в СУБД, где их из коробки нету (например, MS SQL).

Более того — мы потенциально можем строить специализированную версию функции для каждого регулярного выражения, и у нас не будет компиляции строки на каждое обращение к кортежу (как было бы при втаскивании в СУБД единственной функции Regex(string data, string pattern)