![[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
no subject
2) языки программирования высокого уровня не оперируют множествами?
no subject
А по второму - вроде только LINQ и оперирует, а все остальное при работе с множествами таки на порядок многословнее чем SQL
no subject
no subject
Ну, я вот тоже не вижу противоречия между обоими подходами. Очевидно, что аггрегацию, сортировки и вообще все что хорошо ложится на SQL надо делать в базе, а всякую императивную интеллектуальщину - лучше на обычном языке.
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
Звучит как угроза!
Но таковой не является, на самом деле, никакую логику не надо реализовывать на уровне СУБД, если речь идет о бизнес-логике, конечно.
Да, очень многие бизнес-логику фигачат прямо на PL/SQL или на T-SQL или что они там знают, но это от отсутствия культуры разработки и общей эрудиции.
А что было бы со стартапом, когда завтыкала бы бизнес-логика в движке сервера, а не извне? Люди цепляли бы профайлер к движку? Если они не умеют к своему собственному приложению профайлинг прицепить, как они сделают это к чужому?
Когда логика извне можно, хотя бы, СУБД сменить (с платной на бесплатную или наоборот, в зависимости от бизнес-требований).
no subject
Сразу видно профессионала.
no subject
Сейчас изучу этот вопрос подробнее.
no subject
Я бы, пожалуй, начал с описания модели безопасности - какие есть объекты и субекты и как они должны соотноситься.
У нас модель безопасности была очень облегченной по ряду причин, тем не менее, были роли и группы ролей, вот только объектом был весь воркфлоу.
Что для системы с уклоном имено в документооборот вряд ли приемлемо.
no subject
Но, поскольку объект был достаточно крупный, стоимостью проверки вообще можно было пренебречь, что неинтересно.
А если задача стоит не пренебрегать стоимостью проверки, я бы сделал DAO layer как будто никакой безопасности нет, а к самим аксессорам прибил бы аспекты, и аспектно проверял бы права.
При этом, информацию о правах я бы тянул прямо в аксессоре, чтобы из аспекта в базу не ходить.
no subject
Права - это, практически, свойства объекта.
Аспект - это, практически, обработчик события.
Проверка прав будет происходить при наступлении события "обратились к".
Если же система прав накладывает существенные ограничения на размер выборки, то я бы такую систему прав выкинул, либо выборку делал бы как-то иначе.
Да, в случае необходимости существенно резать выборку именно правами на клиенте - расходы будут, согласен.
Но это тогда не система прав, а нечто прямо из ада.