Кто как укладывает бизнес правила в БД?

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

Александр Асосков, правила - часть логики, хранить ее в субд - плохо и геморно
Давать создавать такие правила пользователю - чревато

sim3x, Скажем так система закрытая правилами рулят те люди которые отвечают за бизнес аналитику

Александр Асосков, что никак не отменяем мою реплику

Хранить в бд код - не нужно

Нужно давать право записи "аналитикам" в файл, который будет наполнятся правилами
И пусть они пишут какие угодно правила на пхп

sim3x, На PHP аналитик точно писать не будет лучше интерфейс(конструктор) правил из простых элементов составляет правело

Александр Асосков, не будет на пхп - пусть на питоне пишет

Не умеет на питоне пусть на R
Не умеет на R - профнепригоден

Пилить интерфейс для детей - конечно прикольно, но на выходе имеем кучу ограничений и кучу кода для верификации

sim3x,
да какая разница где ее хранить в статике или в динамике, тут вопрос в возможности ее изменения/создания

diamond, действительно, кому нужно версионирование кода и дифы?

Причем тут версионирование. Вопрос как хратить в структуре базы данных динамические бизнес правила и редактировать на фронте например вот эта такая библиотека для фронта как пример querybuilder.js.org/demo.html

Все это конечно замечательно но задача поступила лично от заказчика и он вполне осознает чего хочет.

он вполне осознает чего хочет

Я выскажу лишь свое мнение.

Когда заказчик хочет вот такие универсальные вещи, то он сам не знает, что он хочет.

Если бизнес-правила вам описывают "ну, например, хрен и морковка, бярк и капуста", то он сам ничерта не определился с хотелками, а потому перекладывает ответственность на вас и уникальную свителку, которую он хочет.

Попросите его сформировать десяток реальных правил, чтобы "вы могли разработать правильный язык". И я очень удивлюсь, если язык для правил всё ещё понадобится.

Главное не выполнить все хотелки заказчика. Главное чтобы заказчик ушел с продуктом, который ему реально нужен, пусть он его видел и не таким )))