У
я видел два адекватных варианта. Либо используется ORM, либо DBA делают хранимки и дергаются хранимки. Вариант с "разрабы руками пишут SQL" практически всегда приводит к проблемам.
Плохие разрабы
Size: a a a
2020 September 28
PD
зачем тогда все эти корутины и асинхроны, он же синхронный
Так пока с большей частью SQL баз и нельзя работать асинхронно (драйвера есть, но не ко всем базам и пока еще сырые).
Но у меня не SQL, так что мне и не нужно про это думать.
Но у меня не SQL, так что мне и не нужно про это думать.
PD
Можно сделать асинхронную обработку на синхронной базе и jdbc.
Ну, с транзакциями будет сложно. И все равно число коннекций сильно ограничено, хотя вывернутся можно, конечно.
SB
Так пока с большей частью SQL баз и нельзя работать асинхронно (драйвера есть, но не ко всем базам и пока еще сырые).
Но у меня не SQL, так что мне и не нужно про это думать.
Но у меня не SQL, так что мне и не нужно про это думать.
Говорят есть какой-то r2dbc, но насколько это рабочий вариант хз. Вроде пишут что работает с какими-то БД.
PD
я видел два адекватных варианта. Либо используется ORM, либо DBA делают хранимки и дергаются хранимки. Вариант с "разрабы руками пишут SQL" практически всегда приводит к проблемам.
Хм, ни разу не видел от этого проблем. Вот от ORM - видел и еще как. Да и от хранимок видел.
PD
Говорят есть какой-то r2dbc, но насколько это рабочий вариант хз. Вроде пишут что работает с какими-то БД.
Ну, есть для PG, но пару лет назад был дико сырой, что сейчас - не знаю, не пробовал. Там все равно нужно думать про всю цепочку от приложения до распределения процессов внутри СУБД.
PD
Всё не так просто. Кто-то должен ручками прописывать DDL, структуру таблиц, индексы и пр.
Поэтому, из моей практики, часто нужно иметь всего пару человек в команде, кто хорошо знает конкретную базу и пишет скрипты. Именно "их" код ложится в liquibase/flyway. Остальные спокойно могут использовать ORM.
Поэтому, из моей практики, часто нужно иметь всего пару человек в команде, кто хорошо знает конкретную базу и пишет скрипты. Именно "их" код ложится в liquibase/flyway. Остальные спокойно могут использовать ORM.
Хм, у меня и DDL всегда писали разработчики - и никаких проблем.
Вообще, работы с БД в проекте обычно очень мало, откуда вообще столько внимания к этой задаче?
Вообще, работы с БД в проекте обычно очень мало, откуда вообще столько внимания к этой задаче?
GK
Асинхрон - не самоцель. Не обязательно делать все операции асинхронными, чтобы уменьшить время отклика и увеличить пропускную способность.
LV
@dphil Т.е. ktor выбрали больше по функциональным требованиям? Производительность решения по сравнению с spring стэком не сравнивали?
EM
Плохие разрабы
ну, я не очень понимаю, почему знание БД вдруг стало мастхэвом. На несколько сотен микросервисов в базы ходят два десятка. Проще либо доверить эту работу спецу, либо воспользоваться библиотекой. И да, естественно речь не о случаях select * from и простых джойнов.
PD
@dphil Т.е. ktor выбрали больше по функциональным требованиям? Производительность решения по сравнению с spring стэком не сравнивали?
С чем именно из спринга? По сравнению с обычными сервлетами - у ктора все на порядки лучше.
Но при чем тут спринг?
Но при чем тут спринг?
LV
webflux
PD
webflux
А на эту гадость мне хватило один раз посмотреть )
PD
ну, я не очень понимаю, почему знание БД вдруг стало мастхэвом. На несколько сотен микросервисов в базы ходят два десятка. Проще либо доверить эту работу спецу, либо воспользоваться библиотекой. И да, естественно речь не о случаях select * from и простых джойнов.
У меня по опыту есть корреляция: те, кто не умеют в БД - не умеют и вообще в понимание транзакций, гарантий и так далее.
GK
Хм, у меня и DDL всегда писали разработчики - и никаких проблем.
Вообще, работы с БД в проекте обычно очень мало, откуда вообще столько внимания к этой задаче?
Вообще, работы с БД в проекте обычно очень мало, откуда вообще столько внимания к этой задаче?
На самом деле у каждой СУБД много специфики. Вряд-ли вспомню детали, но у меня в голове отложилось два момента:
- специфику СУБД точно нужно знать
- в команде редко бывает много людей, которые знают специфику конкретной СУБД
- специфику СУБД точно нужно знать
- в команде редко бывает много людей, которые знают специфику конкретной СУБД
PD
На самом деле у каждой СУБД много специфики. Вряд-ли вспомню детали, но у меня в голове отложилось два момента:
- специфику СУБД точно нужно знать
- в команде редко бывает много людей, которые знают специфику конкретной СУБД
- специфику СУБД точно нужно знать
- в команде редко бывает много людей, которые знают специфику конкретной СУБД
Ну, не так много специфики, на самом-то деле. И она очень быстро приходит к разработчику.
Ну, если совсем сложные запросы - то показывали DBA или просили помощи. Но это редкость.
Ну, если совсем сложные запросы - то показывали DBA или просили помощи. Но это редкость.
PD
(Сложные - это те, что на ORM вообще не сделать)
GK
Ну, не так много специфики, на самом-то деле. И она очень быстро приходит к разработчику.
Ну, если совсем сложные запросы - то показывали DBA или просили помощи. Но это редкость.
Ну, если совсем сложные запросы - то показывали DBA или просили помощи. Но это редкость.
Вот даже чтобы в Oracle (условном) правильно индексы создать, нужны знания которые часто выходят за рамки компетенций среднего разработчика.
p
Nikolay
Подскажите какие есть прелетв у poll подхода? Вот если есть гипотетическое приложение , которое каждые 3 секунды опрашивает сервер на наличие изменений. В какое ограничение физически оно упрется,если количество таких клиентов начнет расти
Полоса до сервера кончится
PD
Ну, это всего лишь значит, что DDL должен просмотреть DBA. Но это скорее про review, нежели про разработку.