Topic: Input wanted on Data Model design

Hello all!  I'm new here (coming from mainly a Java & PHP background).  I'm designing an application, and excited to try all that Rails has to offer.

My question is on the best practice for structuring my models.  I have the following requirements:

1. Three very different types of users will have access to the application: Customers, Plan Admins, and Content Admins
    - All three User types require a username, email, and password
    - Customers are also required to provide several other fields (address, birthdate, etc.)

  2. Customers can buy our Plans, Plan Administrators can track and update those Plans, and Content Administrators can see limited customer data, not mess with the Plans, and access some other administrative areas of the application.

I'm a little lost on what would be considered a best practice for accomplishing all of this.  I've read a lot on Devise and CanCan as ideal authentication and authorization modules.  Are those a better solution than just having three different User types which all descend from the User class?

Additionally, does anyone have suggestions for a way to let our Admins sign-up that would be separate and secure from where our Customers sign up?

I just don't want to start down the wrong path here and have to rebuild everything down the road.  Any help would be greatly appreciated!

Re: Input wanted on Data Model design

I would probably have a single User model and then allow a User to have one or more roles.  This strategy works well with something like CanCan. Have you watched the Railscasts CanCan screencast?

Re: Input wanted on Data Model design

Thanks for the reply!  I actually stumbled upon that video the other day, and it was very helpful.  Right now, I'm leaning towards this:

1. A user model which only stores username, email, and password
2. A roles model (with CanCan) that implements permissions
3. A separate profile model which holds all of the other fields (optional or required based on role), such as address, phone number, etc.

Does that seem reasonable?  Would it make sense to have a separate profile model for each type of profile (e.g., a Customer Profile model, an Administrator profile model, etc.)?