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

Gt_>ерунда. как рсубд уже 2-3 раза в своей истории доказали что никому не нужно хранить вермишель из кривых структур языка, т.к. вермишель лишь в студенческих задачках гладко работает, а в реальных условиях не масштабируется и требует диких трудозатрат и костылей.
На этой "вермишели", фактически, написан весь современный Интернет. От Амазона до Гугла.

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

S>Тогда программам потребуется Software Transactional Memory. Потому что даже если пренебречь тем, что программа вынуждена время от времени выключаться — штатно или нештатно — нам всё ещё нужно обеспечивать свойства типа атомарности и изоляции транзакций.
Не обязательно нужно. Можно обходиться eventual consistency и периодическими reconciler'ами.

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

Gt_>в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет.
ORM и статические языки смотрят в недоумении.

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

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

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

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

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

не надо передавать, не надо делать копию объекта в памяти. не надо потом тратить на GC.

Gt_>>в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет.
C>ORM и статические языки смотрят в недоумении.

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

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

A>Какая пропасть? Логика в базе это именно "ужас-ужас", которым стоит заниматься только в случае крайней необходимости. Базе -- данные, приложению -- логику!!!))
Ну, вы же почему-то доверяете базе обрабатывать логику джойнов? Или вы поклонник NoSQL?
Почему же вы не хотите доверить базе что-то чуть более сложное?

A>Конечно, нужен баланс. Но в любом случае на сервере приложений больше простора для написания логики, начиная от выразительности языка, заканчивая набором библиотек.
Ещё раз подчеркну: абстрактных соображений вроде "больше простора" при принятии архитектурных решений лучше избегать.
Единственный правильный способ — это для каждого конкретного случая сравнивать конкретные характеристики.

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

А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений.
Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).
При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.

Но данное решение даже в голову не приходит тем, кто думает мантрами типа "логика в базе — это ужас-ужас".

ЭФ>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
А что плохого?
По-твоему скольки процентам БД когда-либо потребуется масштабирование? Эта цифра больше пяти?

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

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

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

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

Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов.

Ну и, вообще-то, регэкспы уже есть в виде встроенных функций чуть менее, чем во всех нормальных РСУБД. Какие ещё варианты для функций есть?

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

S>Ну, вы же почему-то доверяете базе обрабатывать логику джойнов? Или вы поклонник NoSQL?
S>Почему же вы не хотите доверить базе что-то чуть более сложное?

Доверяю, потому что в моем понимании джойны, выбороки и проекции это не совсем уровень бизнес-логики, это уровень доступа к данным. Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?

S>Ещё раз подчеркну: абстрактных соображений вроде "больше простора" при принятии архитектурных решений лучше избегать.
S>Единственный правильный способ — это для каждого конкретного случая сравнивать конкретные характеристики.

Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.

И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?

А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?

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

S>А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений.
S>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).

Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.

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

Здесь вообще не понял про что речь. Статическая компиляция регулярки?

S>Но данное решение даже в голову не приходит тем, кто думает мантрами типа "логика в базе — это ужас-ужас".

Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.

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

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

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

кеш уже есть в субд. делать копию этого же кеша что бы там что-то запускать быстрее не будет.

C>Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов.

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

C>Ну и, вообще-то, регэкспы уже есть в виде встроенных функций чуть менее, чем во всех нормальных РСУБД. Какие ещё варианты для функций есть?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A>Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?
В локальности.

A>Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.
Ну и что?
A>И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?
Как раз я предлагаю не ограничивать. Это вы хотите ограничиться логикой в app server.
A>А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?
В зависимости от конкретной задачи. Тут универсальными мантрами не отделаешься.

S>>А ведь технически ничто не мешает скомпилировать регекс в байткод, и запихать его внутрь СУБД. Где он будет исполняться со скоростью мысли, и сэкономит 90% трафика между СУБД и сервером приложений.
S>>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).
A>Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.
За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
S>>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.
A>Здесь вообще не понял про что речь. Статическая компиляция регулярки?
Конечно. Вы же знали, что регулярку можно скомпилировать, а не интерпретировать?
A>Бизнес-логика заканчивается на регулярных выражениях? Хорошо живете.
Я намеренно привожу простой пример. Нет смысла обсуждать сложные вещи в бизнес-логике, пока вы не поймёте технические основы.

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

A>>Доверяю, потому что в моем понимании джойны, выбороки и проекции это не совсем уровень бизнес-логики, это уровень доступа к данным.
S>Ну, и где же граница?

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

A>>Но мы же не про sql говорим, а про процедурные расширения. В чем преимущества plsql/tsql перед java/c# как инструмента для обсчета и преобразования, когда данные уже выбраны из таблиц?
S>В локальности.

Единственный плюс. Но если рассматривать архитектуру всей системы в целом, его даже не стоит принимать во внимание.

A>>Какие же они абстрактные? Как языки plsql и tsql (на фоне java и c#), мягко говоря, полная ерунда. Библиотек нормальных нет, коллекций нормальных нет, сахара минимум. Вообще странно, что их называют языками для обработки данных.
S>Ну и что?

Как что? Элементарных вещей в этих языках нет, бери любую возможность из современного языка, и не найдешь ее. Про коллекции я уже говорил, еще нет пространств имен (привет, библиотеки), нет подобия linq to objects (хотя казалось бы, данные же обрабатывем), нет кортежей (и это языки расширения в рсубд), нет вывода типов, нет рефлексии, а следовательно нет и мапперов. Да ничего там нет, кроме временных таблиц, и в результате все проблемы выглядят как гвозди.

A>>И зачем себя ограничивать в архитектурных решениях? Если возникнет задача, которую не решить процедурными языками базы из-за отсутствия нужных библиотек, то что делать? Сказать, что не можем? Писать внешний сервис?
S>Как раз я предлагаю не ограничивать. Это вы хотите ограничиться логикой в app server.
A>>А если расчеты начнут нагружать процессор на сервере базы, как будете масштабировать решение?
S>В зависимости от конкретной задачи. Тут универсальными мантрами не отделаешься.

Вы уж определитесь: "стоит избегать" или "не ограничиваете". Вот есть у вас какой-либо расчет на plsql/tsql. Условно, при закрытии месяца база у вас ложится, потому что этот расчет очень любит процессор. Как будете выходить из положения?

S>>>Заодно это позитивно скажется на времени удержания локов (или на шансах нарваться на конфликт при оптимистике).
A>>Каким образом? За счет скорости выполнения? А она точно будет существенно больше? Например, относительно использования dapper или linq2db.
S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.

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

S>>>При этом всю рутинную работу по проверке соответствия версии регекса, которая нужна клиенту, и версии регекса, лежащей в базе, можно возложить на тупую неутомимую машину, а не на рассеянные кожаные мешки.
A>>Здесь вообще не понял про что речь. Статическая компиляция регулярки?
S>Конечно. Вы же знали, что регулярку можно скомпилировать, а не интерпретировать?

Так еще со времен перла. А при чем здесь версия регулярки на базе и на клиенте? Что такое вообще версия регулярного выражения?

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

А вы приведите сложный. Вы же библиотеку регулярных выражений не на plsql/tsql писали, эта возможность вам любезно предоставлена самим движком субд. Кстати, если бы не было регулярок в движке, как бы выходили из положения?

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

S>За счёт того, что канал между памятью и диском в сервере БД существенно шире, чем канал между апп.сервером и сервером БД.
S>При хорошей селективности предиката в апп.сервер поедет в сотню раз меньше данных, и СУБД сможет завершить транзакцию раньше.
Тут надо штаны или крестик. Хранимые процедуры в существующих РСУБД, фактически, не оптимизируются никак. Они просто применяются как фильтр к выбранным строкам.

Если у нас процедура должна обработать 100500 тонн данных, то это будет уже не OLTP. А если не OLTP, то стоит ли корёжить архитектуру ради того, чтобы квартальный отчёт будет составляться 10 минут вместо 20? Если же не нужно передавать 100500 тонн данных, то какие проблемы их закинуть на клиента?

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

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

C>>Типичный пример — строка с автокомплитом, чтобы можно было по "ка ма 12" показывать вариант "ул. Карла Маркса, д. 123" из базы клиентов.
Gt_>угу. а потом ныть что примитивный сайт кушает 1.5GB и что бы просто побровсить нужна машина минимум с 8Gb рам и SSD.
SSD-то зачем? Кэш в памяти. Если при этом приложение будет работать быстрее, чем глаз замечает задержку, то пользователям будет совсем пофиг сколько там терабайт памяти серверу нужно.

C>>Ну и, вообще-то, регэкспы уже есть в виде встроенных функций чуть менее, чем во всех нормальных РСУБД. Какие ещё варианты для функций есть?
Gt_>задачи бывают разные, как выше заметили важен баланс, а не тупое следование одной концепции. иначе нам скоро и 8Gb уже не хватит что бы побровсить.
Причём тут браузер вообще?