I think using "customer" as a role can be confusing. In business terms, a person isn't a customer until they've purchased something, so you'd be tying the customer role to a previous purchase. Instead, I like to use generic roles that still provide business meaning but from a web application context.
I generally use the following generic roles in my applications: *user* **Anyone that visits the site starts with this basic role, even if they have not authenticated. In other words, a visitor that has not logged in is still considered a user but has no identity. By assigning a role to unauthenticated visitors you can apply ACL rules such as allowing access to certain functions of the website (login, registration, forgot password, view home page, etc.). This also means that there is a User model for these unauthenticated guests because even they have business rules. *member (inherits user)* A member is visitor that has authenticated (use Zend_Auth for this). Once authenticated, the user gains additional privileges (edit profile, buy stuff, etc.) You can also deny registration because they are already logged in. In my code I have the option to continue using the User model but have it return a different role (because it now has an ID) or I could extend the User model. *admin (inherits member)* Admins are just like members except they have elevated privileges (edit other accounts, modify content, etc.). Again, the User model is modified/extended based on my business needs. The nice part about this approach is that you can guarantee you'll always have a User object to query the ACL with, regardless if the user logged in or not. You can always add more roles later to further refine who can do what. With that said, I second Wil's suggestion: use a single table for all of your users regardless of role. You can easily add a "role" field to the table to keep track of them, and you won't have to duplicate your table structure. -- *Hector Virgen* Sr. Web Developer Walt Disney Parks and Resorts Online http://www.virgentech.com
