В отличие от ответа Кароль, я также использовал Drools, но у меня был отличный опыт с ними. Варианты использования в документации намеренно упрощены, но Drools также может обрабатывать гораздо более сложные варианты использования более эффективно, чем база данных. Я знаю это наверняка, потому что сервис, который я поддерживал с ~ 1,4 миллионами правил, был преобразован в использование базы данных (используя те же аргументы, что и вы). В среднем от 30 до 100 мс на ответ на запрос уходило от 750 мс до более 2 минут на ответ (насколько дольше я не знаю, потому что у нас истекло время ожидания наших запросов через 2 минуты.)
Причиной этого было то, что Drools позволил нам реализовать логику "провалиться" c. В этом случае мои 1,4 миллиона правил определяли, нужно ли больному пациенту разрешение от его страховки, чтобы сделать процедуру в больнице. Правила варьировались от очень общих до очень конкретных; если два правила соответствуют входным данным, мы предпочитаем более конкретное c правило. Особые случаи применения применяются, если в определенной комбинации c больница или больница + страховка имеется специальное правило. Мы передали все данные, которые мы знали о пациенте, всей его истории болезни, и тонну информации об их страховке, а затем правила определили ответ.
Представьте себе этот намеренно упрощенный сценарий:
rule "Car"
when
Car() // very simple, I have a car
then
setPrice(100)
end
rule "Red Car"
when
Car( color == "red" ) // I have a red car
then
setPrice(75)
end
rule "4-door Car"
when
Car( doors == 4 ) // I have a 4-door car
then
setPrice(200)
end
rule "Red Sedan"
when
Car( color == "red", model == "sedan") // I have a red sedan
then
setPrice(500)
end
rule "Blue 4-Door Discount"
when
Car( doors == 4, color == "blue") // I have a blue 4-door car
then
setPrice(150)
end
Теперь мы начинаем играть в разные конфигурации автомобилей. Желтый автомобиль, 2-дверный спортивный автомобиль соответствует только первому правилу, а цена равна 100. Красный 4-дверный автомобиль соответствует двум правилам; цена 75 или 200? Зависит от того, как вы написали свои правила и что делает «установленная цена»; скорее всего, в правилах, которые я здесь написал, цена 200. Синий седан? 100. И так далее.
Если бы мы преобразовали это в таблицу базы данных (для простоты, в одну таблицу Car со столбцами 'color', 'model' и 'doors'), как бы выглядел этот запрос? (На самом деле я не знаю, что мне не удалось написать запрос, который был бы достаточен; я также не администратор баз данных.)
Я мог бы привести целый ряд примеров, где на основе базы данных Решение будет менее эффективным или не рекомендуется вообще. Например, однажды я реализовал алгоритм psuedo-BFS, используя правила, чтобы определить оптимальный путь обновления от произвольной аппаратной конфигурации до последней поддерживаемой конфигурации. (Каждая версия может быть обновлена только до отдельных других версий, поэтому нам нужно было выяснить самый быстрый путь от данной версии к целевой версии, если это возможно.) Может ли это быть сделано в базе данных? Возможно, но это не та вещь, для которой был бы полезен реляционный БД. Как насчет кода? Конечно, но теперь вам придется управлять своим списком «что можно обновить до чего» в коде.
Для чрезвычайно простых наборов правил, где каждое правило является полностью эксклюзивным и охватывает все варианты использования? Конечно, база данных может быть более производительной. Однако в реальных ситуациях потребуются слишком сложные запросы или они могут вообще не подходить.
И таблицы решений? Избегайте их любой ценой. Они медленно загружаются, медленно выполняются, занимают больше памяти, чем им нужно, имеют недокументированные ограничения, с которыми вы столкнетесь, если попытаетесь использовать их в масштабе, и отладка - это боль.