Каковы мифы о правилах?

Ответ 1

Я не знаю о мифах, но я согласен с тем, что соблюдение правил ведения бизнеса не является препятствием.

Я думаю, что ожидая, что деловые люди получат терпение и внимание, уделяя внимание деталям, необходимым для работы на ИТ, - это фантазия. Он был в игре с тех пор, как языки 3G (графические подходы к программированию) были предложены как способ заставить секретарей писать код, чтобы все программисты могли быть уволены.

Я бы отметил, что по мере увеличения размера набора правил вероятность того, что он будет исправлен и самосогласован, снизится. Если ваш набор правил содержит тысячи правил, это будет трудно проверить.

Говоря об этом, комбинаторный взрыв комбинаций затруднит проверку механизма правил.

Двигатели правил - потрясающая технология, но будьте осторожны.

Ответ 2

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

Один, который я обязательно добавлю в список:

Миф: двигатели правил медленны!

Не так, опять же, я пропустил даже тысячи событий в секунду с помощью слюни довольно легко.

Другой, который я совершенно ненавидел, был:

Миф: он слишком тяжелый и сложный для использования.

Глупость, синтаксис тривиальна и с несколькими строками java, вы можете сделать некоторые действительно фанки! Извините, если это похоже на напыщенность, были месяцы этого дерьма у предыдущего работодателя, поскольку я пытался внедрить эту технологию!

Ответ 3

Мифы...
1/Бизнес-пользователи могут:
правила автора
развернуть их
протестировать их
запустите их
Без помощи ИТ... Я поставил тренинг для клиента, который на самом деле думал, что это правда, потому что продавец сказал так... ах ах ах они сделали мой день/месяц/год!!!

Можете ли вы серьезно подумать о компании, которая будет рисковать для развертывания службы в задней части ИТ-команды? нет! Вам также нужна безопасность, чтобы я не написал правило:
если имя клиента "Damien", то скидка 100% - groovy baby!

Архитектура проекта не может быть выполнена нетехническими пользователями

2/Вы можете легко управлять проектом правил, не беспокоясь ни о чем. Существует ограничение количества правил, с которыми вы можете иметь дело. Теоретически можно иметь столько правил, сколько они хотят, но это не совсем правильно. JRules останавливает синхронизацию правил между Eclipse и RTS примерно с 3000 правил. Это займет навсегда, если у вас есть проект с 100 000 правил, все в RETE. Построение дерева займет много времени. Даже в последовательном режиме требуется много времени.
Вы не можете использовать репозиторий правил, например папку "Мои документы", и просто продолжайте добавлять правила.

3/Бизнес-пользователи могут писать все виды правил без какой-либо подготовки.
Разные вещи:
a/порядок условий может повлиять на производительность.
b/некоторые правила сложны и нуждаются в хорошем понимании языка
c/используемый алгоритм может повлиять на результат выполнения
d/одно плохо написанное правило может умножить время выполнения на n.
Я работал над проектом, в котором за некоторые случайные таймауты отвечало только 1 правило.
e/Некоторая сложная проблема может быть выражена в одном правиле.
Эта проблема решается в одном правиле и имеет один результат:
<Я > Есть четыре гольца, стоящих за чаем, на линии слева направо.
- Гольфист к непосредственному праву Фредса одет в синие штаны
- Джо второй в очереди
- Боб носит брюки из пледа
- Том не в положении один или четыре, и он не носит оранжевые штаны
BTW: Это пример JBoss.
Как бизнес-пользователь может это сделать?

4/Механизм правил может выполнять обратную цепочку
Я думаю, что JBoss говорит, что может, но я не уверен в этом. Blaze и JRules не могут.

5/Для написания правил не нужен какой-либо язык программирования.
Правильно, но вам понадобятся некоторые для выполнения правил. Кроме того, если вы используете простой XSD в качестве объектной модели. Но ваша Служба принятия решений не будет делать так много умной вещи.

6/Это медленнее, чем JAVA Конечно, но, используя BRMS, вы нарушаете бизнес-логику, поэтому она имеет стоимость.
Точно так же, как при экстернализации данных. Вызов базы данных имеет стоимость.
Я отправил 5000 рабочих мест в рабочую память JRules с проектом, содержащим 4 фиктивных правила, которые вызывали друг друга... Цель теста производительности
Результат: 19 миллионов правил, выполненных за 75 секунд. Сделайте свою математику... это не так медленно.

7/Вы можете сделать что-нибудь в правиле
Не делайте запрос базы данных в правиле (особенно в условиях). Используя Rete, теоретически правило может "протестировать" условие, чтобы найти результат сопоставления в памяти тысячи раз.
Никто не хочет вызывать базу данных, которая много в приложении.

Надеюсь, что это поможет.