2

I'm developing this Achievement System and it must have a CRUD, that admins access to create new achievements and it's rules. I need some help with the Achievement CRUD data structure.

Rules sample

Medal one: must complete 5 any courses with a score of at least 90
Medal two: must complete two specific courses with a score of at least 85
Medal three: must be top 5 in general ranking at least once
Medal four: must have more than 5000 points

I'll store that in a SQL database and thought about two options.

Option A

Create a table with a few columns like below to store those multiple variables when suited:

  • action
  • action quantity
  • course quantity
  • score
  • id course
  • ranking position
  • points

Option B

Store that using JSON or serialized format, so all the logic of parsing that is inside my code, downside is it will make it more complex to query some rules (not sure i'll need to query it, but I like to be ready just in case).

Bear in mind there is a high chance that I'll have to add more rules to this system, that's why I'm asking this.

Is there a more suitable way of doing that, perhaps a design pattern, a known solution or something already created for this scenario?

Improve this question
8
  • @DocBrown there is a high chance that I'll have to add more rules to this system, that's why I'm looking for any known solution to this scenario. I only thought about those two options, but I don't favor any of them, just want to know the best way. Commented Dec 19, 2018 at 18:28
  • 1
    This whole dynamic rule system sounds like a lot of work for something that would be fairly trivial in code. You say there’s a chance you’ll need to add more rules later, why don’t you think of those additional rules now? And if you really can’t what prevents you from updating your application later to add more rules? Commented Dec 19, 2018 at 18:48
  • @RikD that's how things are in my work right now, things just pop up in the future. I was just wondering if there is a known solution to this kind of problem that make it easy to add rules, if not, I'll just stick to Option A. Commented Dec 19, 2018 at 18:50
  • The thing is that a system like this might look dynamic, but when the business comes up with crazy new ideas for achievements it really isn’t. What about an achievement for completing a course within a certain time period? Commented Dec 19, 2018 at 19:02
  • @RikD That achievement is likely to be asked in the future. Commented Dec 19, 2018 at 19:03

1 Answer 1

Reset to default
1

There are two general approaches here, for which you have to clarify the requirements first:

  1. Only support a restricted set of predefined rules or rule types. If the rule types need to be extended, some other programmer has to extend the system by adding code and deploying a new version.

  2. Support almost arbitrary rules, and users can extend them by themselves.

I guess this is what you roughly have in mind with your options A and B - but I hope my description makes it more clear that this is not a question of "design patterns" - it is simply a question of the requirement "Who shall be able to extend the rules?".

So given you really need a system where users can extend the rules by themselves, then you could store them as pairs of "boolean expression" and "reward". The boolean expression would be some formula with some predefined functions as building blocks, logical operators "and", "or", "not", and comparison operators, used like

 $NoOfCoursesAboveLimit(90) >=5 $ScoreOfCourse("X")>85 and $ScoreOfCourse("Y")>85 $RankingPosition()<=5 $TotalScore()>=5000

So no fancy "JSON" or "serialization format" involved, just a subset or modification of your favorite programming language, something as user-friend as formulas can be.

Of course, this approach needs probably more effort to be implemented than the first one. One needs to define a grammar, then implement a parser and finally an expression evaluator together with the logic for those predefined functions.

Fortunately, this is not a new problem. For the described case something like the Shunting-yard algorithm should be sufficient for the parsing. The final evaluation step is then just traversing the abstract syntax tree created by the parser.

Improve this answer
4
  • Thinking about it, letting all the decision to create new rules to users is dangerous, the development team should validate that first, so I choose approach number 1, but still all you said has big value to me, thank you very much! Commented Dec 20, 2018 at 12:53
  • @EdsonHoracioJunior: is it so dangerous? Ordinary users do this all the times, using spreadsheets like Excel. Commented Dec 20, 2018 at 13:53
  • I expressed myself wrong, I meant that I don't want users creating new "types" of rules (with new parameters that didn't exist before), but they may create new rules using the ones that already exist. Commented Dec 20, 2018 at 15:50
  • 1
    @EdsonHoracioJunior: even in approach #2, users can only use the basic functions you provide to them, like $NoOfCoursesAboveLimit or $ScoreOfCourse. However, they can combine them in more flexible ways than in approach #1. Commented Dec 20, 2018 at 16:35

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.