Не, ну лет 15-20 назад считалось нормальным и даже немного

модным писать огромные приложения именно целиком на хранимках, почти совсем без клиентской части. Для таких штуки типа pl/sqldeveloper действительно нужны, не в блокноте же такое писать. Но щас вроде такое уже не пишут. Или пишут?

конечно пишут лол

пишут кому нужно решение, недорогое и предсказуемое, а не модное, но дорогое

А как проблемы с версионированием, ревью, и поддержкой обстоят в разработке на хранимках? Мимоджаваразработчик

Если нужно много данных обработать - это лучше делать там, где эти данные лежат.

эти проблемы только в голове )

версионирование, ревью и поддержка только в джаве есть да. в других языках ничего этого нет 😂

так же как и в других языках, настраивают ci/cd, правда мало devops'в кто умеет готовить базы

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

Спасибо. Вроде очевидная истина, но вспоминаю свой опыт разработки в одном банке и как мы там хранимки писали тупо в базу и после просили достойных ребят применить их руками на проде перекидывая код по почте... Короче явно надо мне в эту сторону покопать, попробовать ci настроить

А какие именно проблемы? Код и есть код. Гит и есть гит. Да и тесты писать никто не запрещает.

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

Подтверждаю 😬

А также счета за большинство жкх-услуг.

"проблема" начинается с тем, что код в гите не факт что соответствует реально имеющемуся в БД коду

так это проблема организации разработки в вашем конкретном случае

Если у вас никто не лазает в базу руками - проблемы нет. Если лазает - меняйте флоу разработки.

проблема тут только одна, бд это не только код, но и данные, для которых при миграции придется делать адаптеры, если объекты бд изменились

легаси-кода такого вида очень много, это я более чем в курсе. Вопрос был, пишутся ли такие системы сейчас (новые). Ну пишутся и хорошо...

Как java-разработчик, вы должны быть знакомы с liquebase/flyway.

решения достаточно кастрированные

Нет. Фу. Это определённо НЕ решение версионирования, поддержки и ревью хранимок. Для DDL - да, отличные инструменты, но для кода - фу. Потому что я пробовал.

в простгресе они пишутся вообще прекрасно, и кода в разы меньше получается чем на том же оракле долбаном ) ибо в пг есть прекрасная возможность обмениваться с бэком в json, получать его и отдавать, что дает возможноть работать не просто со значениями, а с объектами и проверять именно объекты а не значения

а если сравнивать средства разработки? Ну например idea для java == datagrip для pl/pgsql ?

Возьмите оракловый xmlobject со схемами

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

спасибо, увольте, сами его берите )

А чем не нравится? Я вот тоже его не люблю, но не более чем JSON и всë другое объектное

а я вообще ничего не люблю из этого ) дело не в любви, дело в удобстве, скорости разработки и производительности )

Поддержка xml - не самая сильная сторона postgresql

а есть бенчмарки какие-нибудь, кстати? Хотелось бы цифр, по сравнению с тем же ораклом.

тут кому что нравится, кто-то в блокноте фигачит и не парится, я например юзал 11 лет pl/sql developer, меня он полностью устраивал, пока работал с ораклом, как перешел на пг - попробовал датагрип и он меня тоже полностью устраивает, для администрирования мне больше нравится юзать pgadmin

как минимум в xml больше байт и от него рябит в глазах, не дружественный он )

Там и с json все прекрасно уже давно)))

Там дело не в banchmark'ах, а в том, что в основе лежит не развиваемый нынче libxml2 (вроде), что приводит, например, к кодированию в эскейп-последовательности любого не-ascii текста (и это в кодировке utf8), баг не могут исправить уже кучу версий из-за ограничений публичного интерфейса библиотеки. Плюс, не все функции генерации xml, доступные, например, в oracle, реализованы в Postgresql (сейчас точно не вспомню, но чего-то не хватает).

Не соглашусь. Если речь о структуре чуть сложнее тривиальной, xml на порядок дружественнее для человека нежели json (предел сложности, после которой json становится трудно воспринимаемый человеком гораздо меньше, чем в xml). А вот для машины json проще, следовательно, дружественнее и быстрее.

и json_path поддержка есть? и тип поля для него даже есть? )

на кой вам читать xml из базы вручную?

не понял о чем вы, да и не особо интересно, давайте каждый при своем мнении останемся данном вопросе

Да

фантастика, какие они молодцы ! а сколько стоит? ) мне надо лицух на 256 ядер всего-то )

Это другой вопрос.

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

Если отбросить вопрос денег, то не соглашусь но это уже холивар.

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

В одном немаленьком банке сейчас наблюдаю вполне успешное применение CI/CD на базе Git + TeamCity + самописного ETL в промышленных масштабах - около сотни разрабов ежедневно коммитят большое количество изменений в Greenplum (= PG 9.6). Там и хранимки, и вьюхи, и куча DDL/DML - и никаких конфликтов нет.

Да и не говорю, что это нереально сделать. Только сложно. ЗЫ Ну, и greenplum -- это почти наверное DWH и аналитика, вещь такая, умеренно ответственная. Точнее, решэния, которые это всё вырабатывает -- ответственные, конечно, но не OLTP и хранение денег по требованиям к надёжности хранилища.