Здравствуйте, Gt_, Вы писали:
Gt_>все таки плюсиков там много больше. например в оракле данные не просто близко, они интегрированы в логику. там есть понятие валидной процедуры/package, если package валидный, значит у него почти нет шансов завалиться в рантайме, код обращается к существующим таблицам, тип колонок именно тот что ожидает код и т.п. в джаве же запросто можно в рантайме получить что угодно, т.к. логика отдельно, данные отдельно.
Так на статической проверке таблиц плюсы plsql и заканчиваются. Для других языков эту проверку можно получить средствами IDE или через тесты.
Gt_>>все таки плюсиков там много больше. например в оракле данные не просто близко, они интегрированы в логику. там есть понятие валидной процедуры/package, если package валидный, значит у него почти нет шансов завалиться в рантайме, код обращается к существующим таблицам, тип колонок именно тот что ожидает код и т.п. в джаве же запросто можно в рантайме получить что угодно, т.к. логика отдельно, данные отдельно.
A>Так на статической проверке таблиц плюсы plsql и заканчиваются. Для других языков эту проверку можно получить средствами IDE или через тесты.
статическую проверку обеспечивает орм, который не приветствуется в высоконагруженных проектах. да и вообще мода на орм отошла. мне кажется spring boot по дефолту даже драйвер jdbc подгружает лениво, гарантирую сюрприз в рантайме.
подсветка синтаксиса в dev среде это конечно круто, но как там карта ляжет с накатом sql скриптов в проде и что там намерджили в релиз вопрос на миллион. потому в джаве так остро стоит вопрос с CI, тестированием. это целое искусство, тогда как pl/sql прилепленный к данным в этом плане дубовей и надежней.
плюсики там еще есть, но прогресс там остановился лет 10 назад.
Здравствуйте, Gt_, Вы писали:
Gt_>статическую проверку обеспечивает орм, который не приветствуется в высоконагруженных проектах. да и вообще мода на орм отошла. мне кажется spring boot по дефолту даже драйвер jdbc подгружает лениво, гарантирую сюрприз в рантайме. Gt_>подсветка синтаксиса в dev среде это конечно круто, но как там карта ляжет с накатом sql скриптов в проде и что там намерджили в релиз вопрос на миллион. потому в джаве так остро стоит вопрос с CI, тестированием. это целое искусство, тогда как pl/sql прилепленный к данным в этом плане дубовей и надежней. Gt_>плюсики там еще есть, но прогресс там остановился лет 10 назад.
Как язык он по-моему с момента появление не развивается. Что толку с этой надежности, если в языке нет ни нормальных коллекций, ни удобных конструций для работы с данными, ни элементарных библиотек. Да и надежность эта без тестов мнимая, если изменения в проде не накатятся, то конкретно plsql ничем не поможет. По скорости тоже, если брать не орм, а raw sql или библиотеки типа dapper, то в большинстве случаев просадка в производительности в работе с таблицами будет не критична, зато появится возможность данные из этих таблиц обработать, используя вес арсенал .net или java.
A>Как язык он по-моему с момента появление не развивается. Что толку с этой надежности, если в языке нет ни нормальных коллекций, ни удобных конструций для работы с данными, ни элементарных библиотек. Да и надежность эта без тестов мнимая, если изменения в проде не накатятся, то конкретно plsql ничем не поможет. По скорости тоже, если брать не орм, а raw sql или библиотеки типа dapper, то в большинстве случаев просадка в производительности в работе с таблицами будет не критична, зато появится возможность данные из этих таблиц обработать, используя вес арсенал .net или java.
толк в том что оракл наката sql скриптов сразу и на сервере покажет, что и где теперь развалилось в коде. и самое главное то оракл не позволит запустить инвалидный пакадж в принципе. жава же пойдет исполнять и вылетит где-то на пол пути, когда уже так просто много чего не отвернуть. особливо это отвернуть весело на хадупах, где все построено на работе с файликами, которые в принципе не имеют понятия транзакции.
и конструкции в оракле вполне с умом и расчетом на джуниор девелопера, тогда как в жава люди и после 7 лет опыта явно не врубаются что цикл, в цикле, запускает цикл нифига не удобство конструкций, даже если эти циклы подсластили синтаксисом stream api. тесты в докере на 3 строки, тянут данные в "нормальные коллекции" (тм) и "удобно" долбят их в циклах, а потом на кластере это все вываливается по памяти. ведь yarn дает лишь пару гигов на процесс и все эти удобства вылезают боком генерируя убытки.
Здравствуйте, Gt_, Вы писали:
Gt_>и конструкции в оракле вполне с умом и расчетом на джуниор девелопера, тогда как в жава люди и после 7 лет опыта явно не врубаются что цикл, в цикле, запускает цикл нифига не удобство конструкций, даже если эти циклы подсластили синтаксисом stream api. тесты в докере на 3 строки, тянут данные в "нормальные коллекции" (тм) и "удобно" долбят их в циклах, а потом на кластере это все вываливается по памяти. ведь yarn дает лишь пару гигов на процесс и все эти удобства вылезают боком генерируя убытки.
Я мало что понял, но если после 7 лет работы у человека проблема с пониманием циклов, то plsql уже точно не поможет.
Здравствуйте, Kswapd, Вы писали: K>Но, кажется, вы не совсем поняли мою мысль (точнее, пересказанную мысль Роберта Мартина из его книги "Clean Architecture"). Дело в том, что само существование RDBMS вытекает из несовершенства устройства компьютеров. Внутреннее устройство RDBMS "заточено" под конкретный тип конструкций с магнитными головками и вращающимися дисками. Быстродействующая оперативная память ограничена небольшими объёмами, к тому же энергозависима, теряет данные после выключения. Поэтому нужно где-то сохранять данные, а после включения загружать их (часть их) снова в RAM для продолжения работы. Но так будет не всегда. Представим себе компьютер с быстрой энергонезависимой памятью гигантского, практически неограниченного объёма. Зачем тогда программам будет что-то куда-то сохранять?
Тогда программам потребуется Software Transactional Memory. Потому что даже если пренебречь тем, что программа вынуждена время от времени выключаться — штатно или нештатно — нам всё ещё нужно обеспечивать свойства типа атомарности и изоляции транзакций.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Lepsik, Вы писали:
ЭФ>>Что же в этом хорошего? База данных — самое немасштабируемое место в системе.
L>Неофитов всегда колбасит от новых идеалогий.
L>Прекрасно все в реляционных базах масштабируется.
Здравствуйте, white_znake, Вы писали:
_>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, white_znake, Вы писали:
_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
Бывает что перекачка данных из СУБД в сервис и обратно становится узким горлышком для производительности, особенно если они живут на разных машинах.
Гораздо быстрее получается выполнить всю логику в самой БД.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, okon, Вы писали:
O>Бывает что перекачка данных из СУБД в сервис и обратно становится узким горлышком для производительности, особенно если они живут на разных машинах. O>Гораздо быстрее получается выполнить всю логику в самой БД.
Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно. Когда у тебя есть отдельный сервер приложений, никто тебе не мешает здесь и сейчас написать процедуру в бд и использовать ее.
A>Здравствуйте, white_znake, Вы писали:
_>>Партицирование, шардирование вполне себе повышают масштабируемость бд. Другое дело, что масштабировать бд — это сложная задача.
A>Это все про хранение данных, чем СУБД и должна заниматься. Вопрос же про код, то есть про сервер приложений, зачем его совать в СУБД?
в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет.
плюс скорость, серьезная логика зачастую требует прокачивать в сервер приложений лишние петабайты.
Здравствуйте, Gt_, Вы писали:
Gt_>в субд есть киллер фичи, которые бывает перевешивают все. например интеграция данных и кода, если DDL изменило типы колонок — база может пометить весь завязанный на эти типы код как инвалид и избавить от множества приключений. сервер приложений же получит эксепшен в рантайме, когда много чего уже и откатить то не выйдет. Gt_>плюс скорость, серьезная логика зачастую требует прокачивать в сервер приложений лишние петабайты.
Петабайты, рсубд, изменение ddl... Мне кажется, что-то здесь лишнее.)
Здравствуйте, amironov79, Вы писали:
A>Здравствуйте, okon, Вы писали:
O>>Бывает что перекачка данных из СУБД в сервис и обратно становится узким горлышком для производительности, особенно если они живут на разных машинах. O>>Гораздо быстрее получается выполнить всю логику в самой БД.
A>Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно. Когда у тебя есть отдельный сервер приложений, никто тебе не мешает здесь и сейчас написать процедуру в бд и использовать ее.
Получается что в итоге часть логики в сервере приложений, а часть в базе и нужно поддерживать оба варианта.
Хорошо когда логика находится в одном месте, а не размазана по разным системам.
Зависит от ситуации, иногда выгоднее всю логику держать в базе, т.к. требуется меньше специалистов чтобы поддерживать все это.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Здравствуйте, amironov79, Вы писали:
A>Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно.
Между "не стоит заниматься преждевременно" и "это же ужас-ужас" лежит целая пропасть.
Есть много нюансов при взаимодействии СУБД и сервера приложений, от которых зависит правильный баланс.
На одном конце спектра мы имеем client-side joins и projections с предикатами отбора, на другом — адский код внутри СУБД.
Есть соображения производительности решения, при которых минимизация объема данных, перекачиваемых между слоями, играет принципиальную роль, и есть соображения производительности разработчиков и службы эксплуатации.
Для которых принципиальную роль играет синхронизация версий между логикой в приложении и в СУБД.
И есть много разных способов эти нюансы учитывать — от написания сложной логики на T-SQL/PL-SQL и до импорта Java/.Net кода в СУБД, или кросс-компиляции управляемого кода в SQL. Где-то в промежутке сидит linq, который позволяет писать логику на шарпе, а исполнять в СУБД.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Хочу добавить, что даже если обработка информации точечная, то, клиент постоянно платит за раунд-трип. При обработке чего-то действительно похожего на логику, вполне легко вылезет 20-50 селектов на всякие проверки. Батчить на клиенте... проще уже процедуру написать (имхо).
Здравствуйте, Sinclair, Вы писали:
S>Между "не стоит заниматься преждевременно" и "это же ужас-ужас" лежит целая пропасть.
Какая пропасть? Логика в базе это именно "ужас-ужас", которым стоит заниматься только в случае крайней необходимости. Базе -- данные, приложению -- логику!!!))
S>Есть много нюансов при взаимодействии СУБД и сервера приложений, от которых зависит правильный баланс. S>На одном конце спектра мы имеем client-side joins и projections с предикатами отбора, на другом — адский код внутри СУБД. S>Есть соображения производительности решения, при которых минимизация объема данных, перекачиваемых между слоями, играет принципиальную роль, и есть соображения производительности разработчиков и службы эксплуатации. S>Для которых принципиальную роль играет синхронизация версий между логикой в приложении и в СУБД.
S>И есть много разных способов эти нюансы учитывать — от написания сложной логики на T-SQL/PL-SQL и до импорта Java/.Net кода в СУБД, или кросс-компиляции управляемого кода в SQL. Где-то в промежутке сидит linq, который позволяет писать логику на шарпе, а исполнять в СУБД.
Конечно, нужен баланс. Но в любом случае на сервере приложений больше простора для написания логики, начиная от выразительности языка, заканчивая набором библиотек.
Здравствуйте, okon, Вы писали:
A>>Ключевое слово "бывает". Получается, что логика на базе это оптимизация, которой как известно не стоит заниматься преждевременно. Когда у тебя есть отдельный сервер приложений, никто тебе не мешает здесь и сейчас написать процедуру в бд и использовать ее.
O>Получается что в итоге часть логики в сервере приложений, а часть в базе и нужно поддерживать оба варианта. O>Хорошо когда логика находится в одном месте, а не размазана по разным системам. O>Зависит от ситуации, иногда выгоднее всю логику держать в базе, т.к. требуется меньше специалистов чтобы поддерживать все это.
Когда требуется меньше специалистов -- это тоже оптимизация.
