Mongo Design question with Rails/Mongoid for a bill tracking app

Question

I'm writing a quick app for a user to track their daily bills (for money tracking purposes). I want the user to be able to define their own categories that a bill can be applicable for. I'm trying however to decide the best way to model this and also validate categories as unique.

My initial thought was this:

class User
  include Mongoid::Document
  embeds_many :bills

  field :categories, :type => Array
end

class Bill
  include Mongoid::Document
  embeded_in :user, :inverse_of => :bills

  field :category
  index :category
end

So a user can add categories, just as strings, and when they add a bill, they'll choose from their available categories for the bill.

So, a couple questions:

1. Does this seem like the proper design? I Don't think it's necessary to define an actual category model as it's literally just a string used to index bills on, but I'm not sure if there are other benefits to a separate model

2. How do I validate_uniqueness_of :categories in my user model. I don't think it works on array items like this, but I could be wrong. I don't want a user to create categories with the same name. I suppose this might be the advantage of a separate model, embedded in the User, but again it seems like more work than necessary.

Can someone tell me my best options here to validate that a user has unique categories (but users can have the same categories, i obviously don't care about that, just unique in the scope of a single user)

Answer 1

[Update]

The design seems proper. In a Rails specific way how would you validate the uniqueness? When adding a category pull the list and do an indexOf check to ensure it doesn't exist. If it does just bounce back an error.

I'm not a Rails guy, let me know if I'm off track or something.

---

I'm not sure MongoDB would be the best choice of storage engines for that. You would be better off using MySQL with a categories table.

Knocks against MongoDB:

• Not ACID transactions
• No single server durability
• Not relational (you want relational for a bill tracking application)