![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Опять же на тему "готовых" решений
В последних постах ![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
yakov_sirotkin про очередь асинхронной обработки задач упоминается, почему они отказались от "готового" решения в виде Oracle AQ: это дело есть только в определенных Edition оракла и при тестировании у них возникли какие-то баги в очередях.
А у меня в двух проектах есть такие задачи, с обработкой очередей. И вот я сразу себе представляю - приезжаем ставить софт, клиент сказал, что у него "есть Оракл", а по приезде оказывается что это Express Edition, а DBA, которые в случае глюков будут разбираться в них, вообще нет. "Сушите весла."
То же самое касается практически всех "готовых" решений для сложных задач, входящих в состав СУБД, ОС или там еще чего-нибудь инфраструктурного. Как только принято решение использовать что-то более сложное, чем базовые функции - с этой системы ты уже никуда не уйдешь и нужно изучать ее "вглубь" и надеятся, что в следующих релизах этот функционал не выкинут, не изменят условия лицензирования, и что он будет работать как надо в других окружениях, и что будет достаточное количество людей, его использующих, чтобы было с кем посоветоваться.
yakov_sirotkin про очередь асинхронной обработки задач упоминается, почему они отказались от "готового" решения в виде Oracle AQ: это дело есть только в определенных Edition оракла и при тестировании у них возникли какие-то баги в очередях. А у меня в двух проектах есть такие задачи, с обработкой очередей. И вот я сразу себе представляю - приезжаем ставить софт, клиент сказал, что у него "есть Оракл", а по приезде оказывается что это Express Edition, а DBA, которые в случае глюков будут разбираться в них, вообще нет. "Сушите весла."
То же самое касается практически всех "готовых" решений для сложных задач, входящих в состав СУБД, ОС или там еще чего-нибудь инфраструктурного. Как только принято решение использовать что-то более сложное, чем базовые функции - с этой системы ты уже никуда не уйдешь и нужно изучать ее "вглубь" и надеятся, что в следующих релизах этот функционал не выкинут, не изменят условия лицензирования, и что он будет работать как надо в других окружениях, и что будет достаточное количество людей, его использующих, чтобы было с кем посоветоваться.
no subject
no subject
Или: Расчёт сальдо при истории хозопераций... круто, где там бизнес логика? Если можно сделать на базе запрос с аггрегацией - его надо сделать.
Вообще засчитывайте что хотите, я столько раз пытался объяснить людям которые всё делают на базе или которые наоборот всё делают на пользовательском интерфейсе зачем нужна трёхзвёнка что жалко тратить время, если человек сам не понял - значит оно ему не нужно было, и может быть что в его области оно и не нужно.
no subject
no subject
2) языки программирования высокого уровня не оперируют множествами?
no subject
А по второму - вроде только LINQ и оперирует, а все остальное при работе с множествами таки на порядок многословнее чем SQL
no subject
no subject
Ну, я вот тоже не вижу противоречия между обоими подходами. Очевидно, что аггрегацию, сортировки и вообще все что хорошо ложится на SQL надо делать в базе, а всякую императивную интеллектуальщину - лучше на обычном языке.
no subject
no subject
no subject