Опять же на тему "готовых" решений

[metaclass]

В последних постах yakov_sirotkin про очередь асинхронной обработки задач упоминается, почему они отказались от "готового" решения в виде Oracle AQ: это дело есть только в определенных Edition оракла и при тестировании у них возникли какие-то баги в очередях.

А у меня в двух проектах есть такие задачи, с обработкой очередей. И вот я сразу себе представляю - приезжаем ставить софт, клиент сказал, что у него "есть Оракл", а по приезде оказывается что это Express Edition, а DBA, которые в случае глюков будут разбираться в них, вообще нет. "Сушите весла."

То же самое касается практически всех "готовых" решений для сложных задач, входящих в состав СУБД, ОС или там еще чего-нибудь инфраструктурного. Как только принято решение использовать что-то более сложное, чем базовые функции - с этой системы ты уже никуда не уйдешь и нужно изучать ее "вглубь" и надеятся, что в следующих релизах этот функционал не выкинут, не изменят условия лицензирования, и что он будет работать как надо в других окружениях, и что будет достаточное количество людей, его использующих, чтобы было с кем посоветоваться.

Comments

[sergiej.livejournal.com]

Никакого проблемного пересечения, приведённые у вас примеры с "логикой" запроса с аггрегационной функцией это банальная ошибка дизайна, места где бизнес логику надо пускать на уровень базы черезвычайно редки.

[sergiej.livejournal.com]

Не хочется флеймить, нравится вам всё на базе делать - делайте.

[sergiej.livejournal.com]

У вас не было вопроса, на что отвечать? На то что "загрузка документа со сложной схемой прав на видимость атрибутов" это логика?
Или: Расчёт сальдо при истории хозопераций... круто, где там бизнес логика? Если можно сделать на базе запрос с аггрегацией - его надо сделать.
Вообще засчитывайте что хотите, я столько раз пытался объяснить людям которые всё делают на базе или которые наоборот всё делают на пользовательском интерфейсе зачем нужна трёхзвёнка что жалко тратить время, если человек сам не понял - значит оно ему не нужно было, и может быть что в его области оно и не нужно.

[sergiej.livejournal.com]

Ага, круто, в первом случае "вызов ХП", внутри там ничего не происходит, просто в поставке оракла уже есть ХП "Списаниие товаа со склада по расходному документу". Круто, тогда конечно первый вариант.

[sergiej.livejournal.com]

1) ну и что? Их от этого что уже программировать и поддерживать не надо?
2) языки программирования высокого уровня не оперируют множествами?

[metaclass.livejournal.com]

По первому - поддержка и программирование SP как бы и сложнее, чем на обычном языке.
А по второму - вроде только LINQ и оперирует, а все остальное при работе с множествами таки на порядок многословнее чем SQL

[sergiej.livejournal.com]

Многословие не порок, порок когда слишком медленно. Базы данных должны хорошо хранить данные и ими быстро оперировать, пользоваться данными в большинстве случаев должен второй уровень. То что производительность при просчёте некоторых вещей лучше на базе - это надо делать на базе. Я вообще не вижу конфликта, меня злит только тупое одностороннее видение: я всё делаю на базе/я всё делаю на ООП/ я всё делаю на визуальных формах.

[metaclass.livejournal.com]

>Я вообще не вижу конфликта, меня злит только тупое одностороннее видение
Ну, я вот тоже не вижу противоречия между обоими подходами. Очевидно, что аггрегацию, сортировки и вообще все что хорошо ложится на SQL надо делать в базе, а всякую императивную интеллектуальщину - лучше на обычном языке.

[sergiej.livejournal.com]

Вот именно. Я видел работающую систему в которой ВСЁ было написано на PL/SQL абсолютно всё, страницы для пользователя в том числе и обработка всего HTTP. Оно работало... скажем так, запросы выполнялись очень быстро, но поддерживать её можно было исключительно: работает? - не трогайте. Интеграция с любой новой системой выливалась в месяцы разработки дорожайшими в мире специалистами, потом месяцами стабилизации. Когда вместо этого посадили пяток студентов, которые за неделю неоптимально и некрасиво присобачивали на жабе "любой каприз бизнеса", то "бизнес" вздохнул свободно, не надо больше ходить на поклон к волосатым хиппи знающим все дебри старой системы, которые кроме прочего умели небольшой ошибкой похерить половину базы.

[vp.livejournal.com]

Хороший пример. Всегда было интересно, какие на него могут быть контраргументы в плане предлагаемой реализации.

[sergiej.livejournal.com]

Какие контраргументы? Делать вместо аггрегационного запроса подсчёт на высоком уровне? Это надо быть психом.

[alexclear.livejournal.com]

Таких мест множество. Начнем с очевидного - монитора безопасности. Если вы не реализуете эту логику на уровне СУБД, то на ее клиенте предстоит всякий раз построчно проверять, надо ли показывать информацию в контексте данного соединения.

Звучит как угроза!
Но таковой не является, на самом деле, никакую логику не надо реализовывать на уровне СУБД, если речь идет о бизнес-логике, конечно.
Да, очень многие бизнес-логику фигачат прямо на PL/SQL или на T-SQL или что они там знают, но это от отсутствия культуры разработки и общей эрудиции.
А что было бы со стартапом, когда завтыкала бы бизнес-логика в движке сервера, а не извне? Люди цепляли бы профайлер к движку? Если они не умеют к своему собственному приложению профайлинг прицепить, как они сделают это к чужому?

Когда логика извне можно, хотя бы, СУБД сменить (с платной на бесплатную или наоборот, в зависимости от бизнес-требований).

[alexclear.livejournal.com]

Вы пиздец какой опасный, "слив защитан", ололо.
Сразу видно профессионала.

[alexclear.livejournal.com]

Ага.
Сейчас изучу этот вопрос подробнее.

[alexclear.livejournal.com]

А, ну монитор безопасности это хорошая тема, сложная.
Я бы, пожалуй, начал с описания модели безопасности - какие есть объекты и субекты и как они должны соотноситься.
У нас модель безопасности была очень облегченной по ряду причин, тем не менее, были роли и группы ролей, вот только объектом был весь воркфлоу.
Что для системы с уклоном имено в документооборот вряд ли приемлемо.

[alexclear.livejournal.com]

Ага, ну у нас где-то такая модель и была.
Но, поскольку объект был достаточно крупный, стоимостью проверки вообще можно было пренебречь, что неинтересно.
А если задача стоит не пренебрегать стоимостью проверки, я бы сделал DAO layer как будто никакой безопасности нет, а к самим аксессорам прибил бы аспекты, и аспектно проверял бы права.
При этом, информацию о правах я бы тянул прямо в аксессоре, чтобы из аспекта в базу не ходить.

[alexclear.livejournal.com]

Размер матрицы ACL - это круто, но откуда возьмутся большие накладные расходы, я опять не понял.
Права - это, практически, свойства объекта.
Аспект - это, практически, обработчик события.
Проверка прав будет происходить при наступлении события "обратились к".
Если же система прав накладывает существенные ограничения на размер выборки, то я бы такую систему прав выкинул, либо выборку делал бы как-то иначе.
Да, в случае необходимости существенно резать выборку именно правами на клиенте - расходы будут, согласен.
Но это тогда не система прав, а нечто прямо из ада.