Народ, хочу посоветовать по архитектуре таблиц в бд, нужно написать

конфигуратор программ лояльности, гибкий что капец, может быть индивидуальная программа, может быть для определенной группы пользователей (например с общий статусом), может действовать как постоянная программа (применяется на каждый заказ если выполнены необходимые условия лояльности), может быть одноразовая программа (если пользователь получил награду, второй раз получить не может), программа может действовать по времени (с 12 до 17), может в определенные дни (8 марта) или периоды (с понедельника по четверг), может быть как награда за определенное достижение (общая сумма заказов превысила какую-то «цифру»), условия могут по разному суммироваться
например: (А или Б) И (С или Д)
и тд…
и это только часть кейсов, как бы писали подобное ?

слона нужно есть потихоньку, маленькими кусочками

для этого слона нужен паттерн

точнее целый мешок паттернов =)

@psytrgles @zmurf @oleksandr_moik что думаете ? может кто-то делал что-то подобное ?

Слишком абстрактно, сомневаюсь, что кто-то возьмется советовать что-то, ибо это разрабатывать надо. Вопрос в чем? Хранишь даты... Если периодичность есть, можно у крона синтаксис взять.

да тут скорее вопрос как это в базу укладывать лучше, видишь ситуация в том, что сами условия разные могут быть, я думаю либо в сторону json-а либо в сторону полиморфных связей, по типу: table loyalti_program_rule: — loyalti_program_id — rule_type — rule_id а дальше уже фигачить истории по типу: date_rules: — start — end time_rules: — start — end status_rules: — status_id и тд и в зависимости от типу правила подкидывать стратегию его проверки

или вообще скомбинировать эту историю, что-то выносить в типы, и в каких-то типах заводить json-ы

да, наверное лучше всего комбинацию сделать, для расширения функционала будет сразу два направления, и так и так можно будет сделать.

Если в выборке не нужно работать по json, то вполне можно и так хранить. Сложно сказать, от ситуации отталкиваться надо. Обычно, если непонятно как лучше, то выбираю один вариант, потом если надо будет уже переделать. Json выглядит пока что проще

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

Что значит адаптивные поля?

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

Хм… звучит как задача с permissions не совсем понимаю зачем вам для этого понадобились полиморфные связи

fields users pages field_entity

приведенная вами схема и есть частный случай задачи с permissions, только названия чуть-чуть поменялись: roles, permissons, model_roles, model_permissions, roles_permissions,

Да, это и есть полиморфия