Size: a a a

2020 December 13

e

evergood in pro.jvm
а это кто
Какая IDE?
известно какая)
источник

а

а это кто in pro.jvm
evergood
известно какая)
IDEA?
источник

e

evergood in pro.jvm
ну да
источник

а

а это кто in pro.jvm
evergood
ну да
В ней встроен гит, поищи)
источник

e

evergood in pro.jvm
а это кто
В ней встроен гит, поищи)
да гит это понятно, я имел ввиду семантическое версионирование
источник

а

а это кто in pro.jvm
evergood
да гит это понятно, я имел ввиду семантическое версионирование
а)
источник

E

Evilo in pro.jvm
Wait, you made it one function
источник

S

Sergei in pro.jvm
Evilo
Wait, you made it one function
Когда-то они научатся участвовать в дискуссии и здраво отвечать на вопросы.
источник

DS

Dmitry Same in pro.jvm
evergood
да гит это понятно, я имел ввиду семантическое версионирование
источник

И

Илья in pro.jvm
Здравствуйте. Попал на новый проект и столкнулся с такой ситуацией, когда архитектор говорит, что бэк с БД будет общаться только через процедуры и функции и сама бизнес логика будет выполняться на БД. На мой вопрос почему так, ответ пока у нас много базистов им же нужно что-то делать. Я вижу только минусы в плане, сложно дебажить (если вообще возможно) процедуры PL sql. А если мы перейдем потом на другую БД?  Есть ли + у такого подхода и можно подсветить еще какие-то минусы. Сама система, грубо говоря бухгалтерского учета.
источник

L

Loljeene in pro.jvm
Илья
Здравствуйте. Попал на новый проект и столкнулся с такой ситуацией, когда архитектор говорит, что бэк с БД будет общаться только через процедуры и функции и сама бизнес логика будет выполняться на БД. На мой вопрос почему так, ответ пока у нас много базистов им же нужно что-то делать. Я вижу только минусы в плане, сложно дебажить (если вообще возможно) процедуры PL sql. А если мы перейдем потом на другую БД?  Есть ли + у такого подхода и можно подсветить еще какие-то минусы. Сама система, грубо говоря бухгалтерского учета.
И часто, вы переходите на другие БД?
источник

SW

Stas Woronkow in pro.jvm
тестирование / поддержка - полный мрак ...
источник

M

Mikhail in pro.jvm
Loljeene
И часто, вы переходите на другие БД?
Для тестов какое-нибудь легковесное in-memory
источник

L

Loljeene in pro.jvm
Вообще вон лигвалео переезжали.
https://habr.com/ru/company/lingualeo/blog/515530/
Возможно была еще статья
источник

KT

Kirill Timofeev in pro.jvm
Илья
Здравствуйте. Попал на новый проект и столкнулся с такой ситуацией, когда архитектор говорит, что бэк с БД будет общаться только через процедуры и функции и сама бизнес логика будет выполняться на БД. На мой вопрос почему так, ответ пока у нас много базистов им же нужно что-то делать. Я вижу только минусы в плане, сложно дебажить (если вообще возможно) процедуры PL sql. А если мы перейдем потом на другую БД?  Есть ли + у такого подхода и можно подсветить еще какие-то минусы. Сама система, грубо говоря бухгалтерского учета.
ну и, к слову, дебажить PL/SQL код не так уж и сложно: https://www.jetbrains.com/help/idea/debugging-oracle-pl-sql-code.html :)
источник

L

Loljeene in pro.jvm
Mikhail
Для тестов какое-нибудь легковесное in-memory
Есть тестконтейнерс. Вообще я против такого подхода
источник

DP

Denis Pavlyuchenko in pro.jvm
Mikhail
Для тестов какое-нибудь легковесное in-memory
@bsideup тут еще работы не початый край :D
источник

И

Илья in pro.jvm
Stas Woronkow
тестирование / поддержка - полный мрак ...
понятно что это редкость, но в прошлом проекте у меня так вышло что с oracle на postgres переходили и вычищали sqlj. И тут я слышал что в далеком будущем будет postgres. По этому такие вопросы и задаю.
источник

SE

Sergei Egorov in pro.jvm
Denis Pavlyuchenko
@bsideup тут еще работы не початый край :D
:D
источник

И

Илья in pro.jvm
Kirill Timofeev
ну и, к слову, дебажить PL/SQL код не так уж и сложно: https://www.jetbrains.com/help/idea/debugging-oracle-pl-sql-code.html :)
Гляну спасибо.
источник