Приветствую всех. Мне необходимо создать функционал, предоставляющий студенту ачивки за некие достижения, вроде: "10 заданий выполнены на 10 баллов", "доля оценок выше 9 больше 90%", "сдано с первого раза" и любая другая (или почти любая), которая может быть придумана менеджером. Я ломаю голову, как эти ачивки динамически в админке создавать, как хранить в бд само условие ачивки, по какой идее в коде их обрабатывать, когда наступает условие достижения ачивки? Может как-то динамически триггеры бд создавать из php, но как превращать человеческое "10 заданий выполнены на 10 баллов" в SQL? За любые идеи буду признателен. Спасибо!
А у них много вариантов? Разобрать согласно заранее созданному словарю. Пример https://www.yaplakal.com/forum2/topic308421.html
Точно пока не знаю, но хотелось бы гибкость какую-то обеспечить и хотя-бы выше перечисленные варианты реализовать. Пример комичный , но можете, пожалуйста, подробнее объяснить? Тогда получается, будут группы типов ачивок, только параметры будет меняться: "доля оценок выше 9 больше 90%", "доля оценок выше 7 больше 70%" и т.д?
пример две таблицы 1 decoration Код (Text): CREATE TABLE `decorations` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `title` varchar(255) NOT NULL, `number_of_times` varchar(255) DEFAULT NULL, PRIMARY KEY (`id`) ) 2 user_decorations Код (Text): CREATE TABLE `user_decorations` ( `user_id` int unsigned NOT NULL, `decoration_id` int unsigned NOT NULL, `current_value` int unsigned NOT NULL DEFAULT '0', PRIMARY KEY (`user_id`,`decoration_id`), KEY `user_decorations_FK_1` (`decoration_id`), CONSTRAINT `user_decorations_FK` FOREIGN KEY (`user_id`) REFERENCES `users` (`id`) ON DELETE CASCADE, CONSTRAINT `user_decorations_FK_1` FOREIGN KEY (`decoration_id`) REFERENCES `decorations` (`id`) ON DELETE CASCADE ) процент выполнения(%) current_value/number_of_times * 100 | 0
универсального решения нет и быть не может, все же комп не человек... можно сделать некий конструктор с ограниченным набором характеристик... например дать работать с полями: <N> задание(й) [выполнено на] <M> балов, с операторами - [выполнено более чем на],[не менее чем на], [менее чем], [сдано с] <N> раза - [не сдано],[сдано более чем с] итд.... суть: некий свой язык шаблонов - предложение, которое состоит и полей <N>, и отношений [больше] [равно] [меньше] пользователю давать конструировать из них предложения....
В базе таблица с названиями "достижений" и таблица-связка для назначения достижений пользователям. Отношение многие ко многим. В PHP набор правил, который запускает расчет для человека либо по расписанию, либо при срабатывании заранее заданных событий. Например, считаем событием сдачу зачета. Нужно реализовать события и подписку на события. Будем реалистами, понадобится и ручной механизм присвоения/отнятия званий. А значит понадобятся права (и роли?) и раздел в админке. Лучше с этого и начать.
После долгих размышлений и поисков, нашёл компонент symfony PHP: symfony/expression-language , который позволяет некий псевдокод интерпретировать или компирирует его на лету в код php, также в него можно закинуть нужные мне объекты для расчёта ачивок в виде переменных. Компонент позволяет на своём языке дергать реальные методы и свойства реальных объектов и писать выражения для расчётов. Остальные библиотеки что я смотрел могут только лишь AST деревья строить либо их нужно допиливать. Своё решение интерпретации на заранее заданных словарях, возможно, было бы более гибким, но отняло бы больше времени и сил на разработку, отладку и тестирование. Всем большое спасибо за предложения, вы дали направления куда искать и что смотреть.
У вас два пути решения: 1. Менеджер берет свои руки и мозги, садится и прикидывает на будущее все варианты ачивок, и отдает его вам в письменном виде. Вы по этому листочку анализируете все варианты, выявляете шаблон и реализуете. 2. Программист пытается написать супер-пупер абстрактный анализатор абстрактного текста - в итоге это займет кучу времени, и в любом случае все варианты покрыты не будут (нет предела фантазиям менеджерам) Выбирать вам. Если вас никто не торопит - можно пойти по второму пути, будет интересный опыт. Но с точки зрения практичности, конечно, нужно идти по первому варианту.
1) таблица пользователей (user_id, email,password) 3) таблица достижений (id, name, status) 2) таблица присвоения достижений (achievement_id, user_id, ... др. поля) Собственно таблица юзеров хранит у нас понятно кого. В табле достижений мы записываем сами очивки - "проснулся вовремя" и т.п., Далее - присвоение очивок: чтобы выдать очивку пользователю мы делаем insert запрос и указваем ид очивки (из таблы достижений), ид юзеру кому она присвоена ну и можно всяких колонок для фильтрации накидать (created_at, updated_at, level и пр.). Вот и всё, далее мы можем легко манипулировать этим набором данных как хотим. Хотим выдать очивку за 10 очивок? При выдаче очивки проверяем таблицу присвоения, если count(user_id) = 10 where achevement_id = ? && user_id = ?, то выдаем очивку за достижение. В общем задача не самая сложная