I am making a Ruby on Rails app and am realizing that my User class could potentially end up with a lot of generic boolean / integer attributes. For example, suppose I have a promotion each quarter, and I only want a person to be able to use the promotion once. Then I’d have to make a new column each quarter has_used_promotion_N to track that promotion.
Alternatively, I’m thinking of creating a new column called “Generic Flags” which is just a comma separated value of flags set on the account. For example:
“has_used_promotion_1, has_used_promotion_2, limit_on_feature_a=20” etc. could be set for some particular user
(or maybe I’ll store it as JSON)
In any case, I’m thinking of giving myself some sort of NoSQL-like functionality in my DB.
Is this really bad design for some reason? Has anyone else done this before? Anything I’m completely missing about RoR?
In my opinion Promotion should be a separate model with a many to many relationship with User. When you have a promotion you would create a Promotion instance and when a person uses that promotion you add that person to promotion.users relationship.
This is much better than your idea because you can now query those relationship. Want a list of all users that used the first quarter promotion? No problem. You can do that with your solution, but you have to resort to some hackiness (is that a word?) to do it, and you’d have to parse the generic flag string for EVERY user on EVERY query. Not ideal to say the least.