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

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

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

A>Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?
Конечно же сервер приложений есть. Мы просто выбираем границу между логикой на стороне СУБД и на стороне апп-сервера оптимальным для каждого запроса способом.
Писать на Pl-sql можно как раз для того, чтобы улучшить throughput.

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

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

S>>Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов
C>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.

Ну вот представь объемы данных для передчи на клиента.
Ты на трафике сдохнешь.

Здравствуйте, Эйнсток Файр, Вы писали:

ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.

Универсальных решений вообще-то нет.
Процедуры могут реализовывать высокоуровневую логику хранения данных. Обновилось поле в какой-то таблице — пересчитать ещё 40+ полей в других. И это вообще-то главная фишка реляционных СУБД, если "целостность" данных не нужна можно взять тот-же elastic, без процедур и с прекрасным масштабированием.
Или когда с базой работает несколько разных приложений, написанных на разных языках. Можно дублировать общий код во всех них, можно запилить ещё одно, абстрагирующее базу данных, а можно вынести общий код доступа к данным в хранимые процедуры.
Или когда сервис работает с небольшим кусочком здоровой и сложно базы данных с тысячами таблиц и полей — проще завернуть взаимодействие в набор простых хранимых процедур, чем на каждый чих лопатить документацию и разбираться какие поля и где запрос должен менять, а какие ни-ни.

Ну и тезис о немасштабируемости все же не совсем корректен. В реляционных СУБД плохо масштабируется один единственный тип операций — согласованные изменения данных. Насчет остального, можно вспомнить к примеру ранний Skype — с хранением данных рассыпанным по тысячам серверов PostgreSQL или Stackoverflow с их экземпляром SQL Server-а.

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

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

C>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
S> Ну вот представь объемы данных для передчи на клиента.
S>Ты на трафике сдохнешь.
Если его супермного, то проблемы будут и у хранимок.

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

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

А какая функция сложная? Генерация изображений, документов, анализ данных за продолжительный период? И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?

S>Потом оказывается, что общей производительности не хватает, и мы выбиваем бюджет на миграции в NoSQL, который лучше шардится и вообще позволяет делать на 250 машинах то, что при толковом проектировании можно было сделать на одной.

Гуглам с майкрософтами можно, а другим нельзя?

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

Эээ, какое отношение sql имеет к хранимкам базы? Тем более sql, сгенерированный linq2db.

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

S>"Вытащить" расчёт из базы как правило помогает мало — просто потому, что его производительность упирается в дисковый обмен. (Обычно никто даже не пытается внести в базу вычислительно-интенсивные вещи, типа мандельброта или блокчейна).

А что мандельброт и блокчейн это уже не бизнес логика?

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

Техника расширить канал между сервером приложений и сервером субд тоже есть.

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

Я все-равно не понял какую проблему вы решали.

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

Компиляция реегулярок тоже не имеет отношения к процедурам в базе. На клиенте базы будет все тоже самое.

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

A>>Мы же про бизнес-логику в базе разговариваем? Где же ее еще писать, если сервера приложений нет? А если сервер приложений есть, то зачем тогда писать что-либо на plsql?
S>Конечно же сервер приложений есть. Мы просто выбираем границу между логикой на стороне СУБД и на стороне апп-сервера оптимальным для каждого запроса способом.
S>Писать на Pl-sql можно как раз для того, чтобы улучшить throughput.

Так с чего и начали разговор: пишем на plsql только для оптимизации.

Здравствуйте, amironov79, Вы писали:
A>А какая функция сложная? Генерация изображений, документов, анализ данных за продолжительный период?
Два основных класса логики, которые не стоит тащить внутрь СУБД: CPU-bound вычисления и Network-bound обмен с внешним миром.
То есть, скажем, отправлять email изнутри СУБД — плохая идея. Или, скажем, делать фильтрацию изображений.
A>И какой будет этот round-trip, если сервера рядом стоят? Где-то есть бенчмарки?
Минимальное время, которое нужно, чтобы сделать select 1 из MS SQL — 10ms. Сколько бар-кодов можно сгенерировать за 10мс?
A>Гуглам с майкрософтами можно, а другим нельзя?
Именно так.

A>Эээ, какое отношение sql имеет к хранимкам базы? Тем более sql, сгенерированный linq2db.
Ок, продолжаем ликбез. Хранимки бывают двух типов в зависимости от использованного языка: это либо процедурный диалект SQL, либо какой-то язык общего назначения.
Я сейчас говорю о первых.
Linq2db — это пример того, как можно использовать язык высокого уровня для порождения SQL. Это помогает обходить синтаксические ограничения SQL по структурированию кода.
К примеру, на SQL крайне тяжело выразить функцию, которая "к любому датасету с int id добавь join с табличкой accessRights", а на linq2db это делается на раз-два:

public static IQueryable<T> CheckAccess<T>(this IQueryable<T> data, int userId) where T:IIdentifyable<int> => from d in data join ar in accessRights on d.ID equals ar.ObjectID select d where ar.UserID == userId;

Очевидно, что данный подход можно распространить за пределы DML, и получить способ для порождения более сложного SQL кода из кода на Java или C#.

A>Хранимки на языках общего назначения, уже, как бы сказать, не совсем хранимки. В каком контексте будет выполнятся код на "неродном" языке? Насколько я понимаю, для базы эта процедура будет выглядеть как внешний клиент, и на переключении контекста можно много потерять (хотя возможно какие-то оптимизации этого дела и есть).
Нет, для базы эта процедура НЕ будет выглядеть как внешний клиент. И переключение контекста бесконечно дешевле обмена данными с апп.сервером на другой машине.

A>При этом набор языков все-равно ограничен, идет привязка к версии рантайма, который идет с данной версией субд, чтобы настроить разрешения, часто надо идти на поклон к админам. В общем, так себе возможность, но на безрыбье сойдет.
Ну, если так рассуждать, то надо сразу вешаться: в эксплуатации для любого чиха надо идти на поклон к админам. А выбирать версию рантайма не даёт ведущий архитектор — ссылается на какие-то непонятные данные опроса клиентов.
A>А что мандельброт и блокчейн это уже не бизнес логика?
Ну, мне, конечно, сложно себе представить бизнес на основе мандельброта; но я вначале поста дал пояснения по поводу того, как выбирать, какую логику имеет смысл тащить в СУБД, а какую — нет.
A>Техника расширить канал между сервером приложений и сервером субд тоже есть.
Ох-хо-хо. Хотел бы я иметь возможность по щелчку пальцев получать между апп.сервером и СУБД такие каналы, как между SSD и памятью на локальной машине.
A>Я все-равно не понял какую проблему вы решали.
Вижу. Всё же сделайте усилие — перечитайте. Если что-то непонятно — спрашивайте.

A>Компиляция реегулярок тоже не имеет отношения к процедурам в базе. На клиенте базы будет все тоже самое.
Я не понимаю, что вы называете "всё то же самое". С точки зрения кода, который пишется прикладным программистом — да, будет всё то же самое. where zipCodeRegex.IsMatch(userAddress).
Вот только исполняться будет всё совсем по другому: вместо подъёма миллиона строк в память апп.сервера и последующего выполнения client-side filter, всё отработает на стороне СУБД. Уменьшаем сетевой трафик на 90%, примерно вдвое сокращаем время удержания транзакции.

Примерно то же самое, только ещё более заметно, работает для классических хранимок вроде "провести резервирование товара по заказу", которые бегают по складам и ищут оптимальный способ раскидать строчки заказа по партиям товара.
Потому что вытаскивание этого в апп.сервер требует N+1 запросов; это очень долго с точки зрения СУБД. Транзакция, которая могла бы закончиться через 400 миллисекунд, занимает десяток секунд.
Всё это время удерживаются блокировки, мешая параллельным транзакциям завершиться — имеем эффект домино. Люди привыкают считать времена отклика в минуту "нормальными".

Здравствуйте, Cyberax, Вы писали:
S>>Ну вот нужно тебе использовать функции которых нет в SQL. Тут либо все тащить на клиента, либо писать хранимые процедуры например для регекспов
C>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер.
Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO. А уже потом делать bookmark lookup, чтобы подтянуть остальные данные для дальнейшей фильтрации или отдачи клиенту. То есть переход от full table scan к index scan — это уже хорошо.
Попытка сделать аналогичный финт в апп.сервере обладает всеми недостатками client side join.

Во-вторых, наличие "хранимки для регекспа" внутри базы позволяет мне делать вычисляемые колонки или индексированные/материализованные view. Что, в свою очередь, переводит запрос из index scan в index seek.

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

S>Два основных класса логики, которые не стоит тащить внутрь СУБД: CPU-bound вычисления и Network-bound обмен с внешним миром.
S>То есть, скажем, отправлять email изнутри СУБД — плохая идея. Или, скажем, делать фильтрацию изображений.

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

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

A>С этим полностью согласен. Тогда о чем спор? Только о границе ответственности между субд и сервером приложений? Тут однозначного ответа нет, каждый выбтрает эту границу, исходя из своего опыта и возможностей.
Совершенно верно. Но, ещё раз: это совсем не то же самое, что просто "процедуры в БД — это же ужас-ужас!"
Нельзя сводить всю вот эту вот сложность к этой фразе. Разве что "свой опыт и возможности" равны нулю — но и то, это скорее повод расширять опыт и исследовать возможности, а не просто говорить "я не понимаю, как делать логику в БД, поэтому не буду её делать".
От этого — один шаг до "я не понимаю реляционки, запилим всё на mongo DB".

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

S>Совершенно верно. Но, ещё раз: это совсем не то же самое, что просто "процедуры в БД — это же ужас-ужас!"

В моем понимании (думаю, и в понимании большинства) процедуры в базе это именно plsql/tsql. И эта фраза относится конретно к этим языкам. Использование же языков общего назначения, как языков хранимых процедур, не особо распространенная практика, производители субд не пиарят эту возможность (так как теряют vendor-lock), а следовательно у этого дела плохая инструментальная поддержка, мало документации. Убедить людей, что, например, писать на java вместо plsql или на c# вместо tsql намного удобнее, практически невозможно.

S>Нельзя сводить всю вот эту вот сложность к этой фразе. Разве что "свой опыт и возможности" равны нулю — но и то, это скорее повод расширять опыт и исследовать возможности, а не просто говорить "я не понимаю, как делать логику в БД, поэтому не буду её делать".
S>От этого — один шаг до "я не понимаю реляционки, запилим всё на mongo DB".

Что вы имеете против NoSql? Xml, json в таблицах не храните?

Здравствуйте, amironov79, Вы писали:
A>В моем понимании (думаю, и в понимании большинства) процедуры в базе это именно plsql/tsql. И эта фраза относится конретно к этим языкам.
Ну, вот видите — оказывается и относится не ко всему, и означает не то, что написано.

A> Использование же языков общего назначения, как языков хранимых процедур, не особо распространенная практика, производители субд не пиарят эту возможность (так как теряют vendor-lock),
Ну конечно же не пиарят. Прямо-таки скрывают от народа.
Про потерю вендор-лока тоже смешно.
A>а следовательно у этого дела плохая инструментальная поддержка, мало документации. Убедить людей, что, например, писать на java вместо plsql или на c# вместо tsql намного удобнее, практически невозможно.
Странно. Буквально пяток ответов назад вы энергично доказывали мне, что писать на java вместо plsql или на c# вместо tsql намного удобнее. И вдруг — такой поворот!

A>Что вы имеете против NoSql? Xml, json в таблицах не храните?
Я даже начинать про это не буду

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

A>>В моем понимании (думаю, и в понимании большинства) процедуры в базе это именно plsql/tsql. И эта фраза относится конретно к этим языкам.
S>Ну, вот видите — оказывается и относится не ко всему, и означает не то, что написано.

Проведите опрос среди базовиков: на каком языке пишутся хранимые процедуры? Думаю, подавляющее большинство не будет знать ничего за пределами plsql/tsql. А если будут, спросите про язык первого выбора для написания хранимки? Думаю 99.99% скажут про plsql/tsql.

A>> Использование же языков общего назначения, как языков хранимых процедур, не особо распространенная практика, производители субд не пиарят эту возможность (так как теряют vendor-lock),
S>Ну конечно же не пиарят. Прямо-таки скрывают от народа.

Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает?

S>Про потерю вендор-лока тоже смешно.

И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно?

A>>а следовательно у этого дела плохая инструментальная поддержка, мало документации. Убедить людей, что, например, писать на java вместо plsql или на c# вместо tsql намного удобнее, практически невозможно.
S>Странно. Буквально пяток ответов назад вы энергично доказывали мне, что писать на java вместо plsql или на c# вместо tsql намного удобнее. И вдруг — такой поворот!

Для меня намного удобнее, прямо небо и земля. Другим надо русскую документацию, обучение по новому для них языку, интеграцию со средой разработки (чтобы им настроили и ткнули пальцем куда код писать), ну и распоряжение руководства, конечно же.

A>>Что вы имеете против NoSql? Xml, json в таблицах не храните?
S>Я даже начинать про это не буду

Ну вот.

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

C>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
S>Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер.
S>Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO.
Ну так и пользовательский код тоже может запросить пары <ID>-<User Address>. Которые будут из того же индекса читаться.

S>А уже потом делать bookmark lookup, чтобы подтянуть остальные данные для дальнейшей фильтрации или отдачи клиенту. То есть переход от full table scan к index scan — это уже хорошо.
Ну так и пользовательский код потом может просто по списку совпадающих ID загрузить таблицу. Если смотреть новомодный GraphQL — там это вообще удобно делается.

S>Во-вторых, наличие "хранимки для регекспа" внутри базы позволяет мне делать вычисляемые колонки или индексированные/материализованные view. Что, в свою очередь, переводит запрос из index scan в index seek.
А вот это вообще лучше не использовать, из соображений сохранения вменяемости.

В принципе, я ещё могу понять использование каких-то очень абстрактных функций в БД, типа regexp match. Это скорее восполнение недостатка самой БД (девелоперы не додумались добавить), но я люто против чего-либо, что связано с бизнес-логикой. Т.е. "ZipMatches" — это уже крайне плохо.

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

A>Проведите опрос среди базовиков: на каком языке пишутся хранимые процедуры? Думаю, подавляющее большинство не будет знать ничего за пределами plsql/tsql. А если будут, спросите про язык первого выбора для написания хранимки? Думаю 99.99% скажут про plsql/tsql.
А если опросить фронтендеров про расшифровку SOLID, то 99% не смогут ответить.
Ну и что? Мы обсуждаем здесь не невежество отдельных представителей профессии, а правильные ответы на сложные вопросы.

A>Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает?
Все, кому интересно .
A>И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно?
Очевидно то, что синтаксис языка играет десятую роль. Всё упирается в нюансы: как устроено взаимодействие с контекстом. Даже если держать всю логику внутри апп.сервера, портирование на другую СУБД — это тот ещё квест.
В реальности написание хранимок на управляемом языке только усугубляет вендор-лок.

A>Для меня намного удобнее, прямо небо и земля. Другим надо русскую документацию, обучение по новому для них языку, интеграцию со средой разработки (чтобы им настроили и ткнули пальцем куда код писать), ну и распоряжение руководства, конечно же.
Всё это уже есть. И документация, и тьюториалы, и интеграция с MS VS. Распоряжение вашего руководства, увы, Редмонд обеспечить не в состоянии.
Да и вообще — руководству, ему ведь помогать надо. Оно "распоряжается" не на пустом месте; работа архитектора — принять решение и обосновать его. Обоснует pl/sql — будут писать на pl/sql. Обоснует java — будут писать на java. Обоснует хранимки на java в oracle — будут писать хранимки на java.
Вот, этот форум — он как раз для архитекторов.

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

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

C>>>А смысл? Хранимки для регэкспоа магически ничего не ускорят, БД точно так же будет вынуждена делать линейный поиск, пробуя каждый ряд. Хранимка спасёт разве что только от того, что эти данные на клиента не надо будет передавать.
S>>Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер.
S>>Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO.
C>Ну так и пользовательский код тоже может запросить пары <ID>-<User Address>. Которые будут из того же индекса читаться.
S>>А уже потом делать bookmark lookup, чтобы подтянуть остальные данные для дальнейшей фильтрации или отдачи клиенту. То есть переход от full table scan к index scan — это уже хорошо.
C>Ну так и пользовательский код потом может просто по списку совпадающих ID загрузить таблицу. Если смотреть новомодный GraphQL — там это вообще удобно делается.
Я вам уже на это заранее ответил: Попытка сделать аналогичный финт в апп.сервере обладает всеми недостатками client side join.
То есть мы говорим о том, что вместо отбора 10% полных записей внутри СУБД, вы предлагаете втащить 100% пар ID-UserAddress в аппсервер, затем сделать фильтрацию, и запихать 10% ID в СУБД, чтобы извлечь из неё 10% полных записей.
Вам уже видно, почему это будет медленнее, чем предлагаемая альтернатива?

C>А вот это вообще лучше не использовать, из соображений сохранения вменяемости.
Да что вы! А что это за соображения — можно озвучить?

C>В принципе, я ещё могу понять использование каких-то очень абстрактных функций в БД, типа regexp match. Это скорее восполнение недостатка самой БД (девелоперы не додумались добавить), но я люто против чего-либо, что связано с бизнес-логикой. Т.е. "ZipMatches" — это уже крайне плохо.
Аргументы?

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

S>>Ну, во-первых, "линейный поиск" СУБД всё ещё может сделать быстрее, чем апп сервер.
S>>Потому, что при where IsZipCodeMatch(userAddress) можно делать "линейный поиск" по индексу, в котором есть только userAddress, что положительно сказывается на объёме дискового IO.
C>Ну так и пользовательский код тоже может запросить пары <ID>-<User Address>. Которые будут из того же индекса читаться.

Откуда появится индекс, если в базе не будет IsZipCodeMatch? Можно, конечно, сделать дополнительное индексированное поле, куда писать результат IsZipCodeMatch сервером приложений, но это будет совсем другой индекс.

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

C>>Ну так и пользовательский код потом может просто по списку совпадающих ID загрузить таблицу. Если смотреть новомодный GraphQL — там это вообще удобно делается.
S>Я вам уже на это заранее ответил: Попытка сделать аналогичный финт в апп.сервере обладает всеми недостатками client side join.
S>То есть мы говорим о том, что вместо отбора 10% полных записей внутри СУБД, вы предлагаете втащить 100% пар ID-UserAddress в аппсервер, затем сделать фильтрацию, и запихать 10% ID в СУБД, чтобы извлечь из неё 10% полных записей.
Нет. Сначала применяем условия, которые не зависят от регэкспа, потом достаём выбираем пары ID-UserAddress, затем на стороне клиента фильтруем.

Всё ровно как в случае с ХП.

S>Вам уже видно, почему это будет медленнее, чем предлагаемая альтернатива?
Не видно.

C>>А вот это вообще лучше не использовать, из соображений сохранения вменяемости.
S>Да что вы! А что это за соображения — можно озвучить?
Использование видов и всяческих вычисляемых колонок — сушит моск и калечит архитектуру.

C>>В принципе, я ещё могу понять использование каких-то очень абстрактных функций в БД, типа regexp match. Это скорее восполнение недостатка самой БД (девелоперы не додумались добавить), но я люто против чего-либо, что связано с бизнес-логикой. Т.е. "ZipMatches" — это уже крайне плохо.
S>Аргументы?
Перекладывание на БД логики. По идее, её там вообще не должно быть.

Даже SQL, по сути, является ошибкой индустрии из-за того, что позволяет часть логики переносить в запросы. Крайне кривой язык, который не приспособлен нормально ни для оффлайновой аналитики, ни для онлайн-запросов.

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

A>>Я про пиар, а не про документацию. У оракла java stored procedures тоже очень хорошо описаны. Но кто про это знает?
S>Все, кому интересно .

Интересно это немногим.

A>>И что смешного? Если система большей частью завязана на проприетарный язык, то портировать ее на другую базу практически невозможно, только переписать. А значит разработчики и пользователи этой системы будут постоянными покупателями данной субд. Разве это неочевидно?
S>Очевидно то, что синтаксис языка играет десятую роль. Всё упирается в нюансы: как устроено взаимодействие с контекстом. Даже если держать всю логику внутри апп.сервера, портирование на другую СУБД — это тот ещё квест.
S>В реальности написание хранимок на управляемом языке только усугубляет вендор-лок.

Каким же образом? Написал модуль на java: хочешь запускай его на сервере приложений, хочешь внутри оракла, хочешь на своей локальной машине. Какой vendor-lock? Возникнет необходимость можно будет запустить на кофемолке или на кофемашине (шутка ).

S>Вот, этот форум — он как раз для архитекторов.

Вон он чё, а я думаю, откуда столько снобизма в ветке?

Здравствуйте, Cyberax, Вы писали:
C>Нет. Сначала применяем условия, которые не зависят от регэкспа, потом достаём выбираем пары ID-UserAddress, затем на стороне клиента фильтруем.
Ну, вот в предположении о том, что регекс отбирает только 10% записей, вы на ровном месте удесятеряете трафик между СУБД и апп-сервером. Зачем?
C>Всё ровно как в случае с ХП.
Нет. В случае с нормальной реализацией, в апп сервер сразу уезжает в 10 раз меньше данных, чем предлагаете вы.
S>>Вам уже видно, почему это будет медленнее, чем предлагаемая альтернатива?
C>Не видно.
Либо вы шутите, либо вам пока рано в трёхзвенку.

S>>Да что вы! А что это за соображения — можно озвучить?
C>Использование видов и всяческих вычисляемых колонок — сушит моск и калечит архитектуру.
Точно — в трёхзвенку рано.

C>Перекладывание на БД логики. По идее, её там вообще не должно быть.
Это странная идея. Ну, то есть идеи-то могут быть любыми, но разработка — она же для людей и преследуемых людьми практических целей, а не для идей. Поэтому "идеи" обсуждать смысла нет.

C>Даже SQL, по сути, является ошибкой индустрии из-за того, что позволяет часть логики переносить в запросы. Крайне кривой язык, который не приспособлен нормально ни для оффлайновой аналитики, ни для онлайн-запросов.
Нет, всё-таки шутите. А я уж испугался )