IZ
Кроме того, как мне несколько нод поднять, если с нагрузкой не будем справляться?
Несколько нод чего?
Size: a a a
2021 January 12
D
Несколько нод чего?
Вот именно: чего? Если логика в приложении, то я могу N инстансов запустить и балансировать нагрузку. А как это сделать, когда логика в хранимках в БД?
IZ
Хранимки страшны как смертный грех по сравнению с кодом на современных языках программирования и фреймворках. Если б вы были единственным человеком в компании и делали все сразу, то ни одной хранимки у вас бы не было, поверьте мне.
Но так как ваш коллега, судя по уровню моего понимания вашей жалобы, даже SQL писать не умеет, то лучше ему вообще ничего не доверять, так как он какими-нибудь рейс кондишонами всю базу в помойку превратит.
Но так как ваш коллега, судя по уровню моего понимания вашей жалобы, даже SQL писать не умеет, то лучше ему вообще ничего не доверять, так как он какими-нибудь рейс кондишонами всю базу в помойку превратит.
Ой да ладно! Средняя хранимка уж точно лучше написана чем средний код сервера приложений на какой-нить сраной яве...
IZ
Вот именно: чего? Если логика в приложении, то я могу N инстансов запустить и балансировать нагрузку. А как это сделать, когда логика в хранимках в БД?
Ну вот, и выходит, что вопрос масштабирования — это не вопрос БД вообще. А комплексный вопрос.
Ss
кто знает как исправить?
D
Ну вот, и выходит, что вопрос масштабирования — это не вопрос БД вообще. А комплексный вопрос.
Да, но если я бизнес-логику держу в БД, то
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
W
Ну вот, и выходит, что вопрос масштабирования — это не вопрос БД вообще. А комплексный вопрос.
Ну вы передергиваете. Как и Дмитрий. Очевидно, что сначала масштабируется приложение путем добавления инстансов. В рамках этого разговора считается что затык в базе и уже надо масштабировать ее. Поэтому спор ни о чем. Масштабируем, конечно, базу, так как все другое уже было сделанно.
am
Ой да ладно! Средняя хранимка уж точно лучше написана чем средний код сервера приложений на какой-нить сраной яве...
Перечитайте сообщение, на которое вы ответили. В нем традиционные фронтенды для JVM уже исключены.
W
Да, но если я бизнес-логику держу в БД, то
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
1) Можешь.
2) Можешь.
3) Можешь.
2) Можешь.
3) Можешь.
IZ
Да, но если я бизнес-логику держу в БД, то
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
Это ерунда.
Можешь, можешь, можешь.
Можешь, можешь, можешь.
D
3 - точно нет. Как вы себе представляете объединить это с коверейджем от кода приложения?
D
И вывести, скажем, значок в github
IZ
Ну вы передергиваете. Как и Дмитрий. Очевидно, что сначала масштабируется приложение путем добавления инстансов. В рамках этого разговора считается что затык в базе и уже надо масштабировать ее. Поэтому спор ни о чем. Масштабируем, конечно, базу, так как все другое уже было сделанно.
Нене, ничего очевидного там нет. Приложение из разных частей состоит и разные части можно масштабировать или не масштабировать, потому что просто это не нужно.
W
Да, но если я бизнес-логику держу в БД, то
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
1) Я не могу масштабироваться
2) Я не могу в тестах мокать
3) Я не могу считать процент покрытия кода проекта тестами
Например мы для тестов поднимаем отдельную Пг, которая слушает только unix socket который ей сказали, заливаем туда структуру БД, прогоняем тесты с моканными данными, а потом rm -rf на эту базу.
D
Я уж молчу, что юниты нормально не прогнать, т.к. БД надо поднимать
W
Нене, ничего очевидного там нет. Приложение из разных частей состоит и разные части можно масштабировать или не масштабировать, потому что просто это не нужно.
Ну, как мне кажется, очевидно что в контексте этого разговора другие средства считаются уже примененными.
D
При чём тут мок данных? Если у вас бизнес-логика подразумевает обращение куда-либо, кроме БД, как вы это мокать будете?
W
Я уж молчу, что юниты нормально не прогнать, т.к. БД надо поднимать
А Юниты вообще - зло. Интеграционка.
IZ
Перечитайте сообщение, на которое вы ответили. В нем традиционные фронтенды для JVM уже исключены.
Не вижу там никаких исключений.