# Logins for customers and admins

**URL:** <https://www.ruby-forum.com/t/logins-for-customers-and-admins/111372>\
**Category:** Rails\
**Created:** [August 6, 2007, 4:37pm UTC](https://www.ruby-forum.com/t/logins-for-customers-and-admins/111372 "2007-08-06T16:37:28Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![jordelver](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9dc877/32.png) [@jordelver](https://www.ruby-forum.com/u/jordelver)\
**Post date:** [August 6, 2007, 4:37pm UTC](https://www.ruby-forum.com/t/logins-for-customers-and-admins/111372/1 "2007-08-06T16:37:28Z")

</div>

Hi,  
I’m trying to figure out how to model my application. I want to have  
two different types of login to the application: Customers and  
Administrators. The users are quite different.

Customers are just that and will be associated with orders, carts and  
the like. Administrators on the other hand will be used to administer  
the site which will include adding, editing, and deleting products,  
editing orders, changing statuses etc. At the moment, there’ll only be  
a couple of Administrators for the system and it’s likely to stay that  
way, but their may be the need for roles to be added in the future so  
that each Administrator can have different rights to perform certain  
actions.

On the one hand, I don’t like the idea of muddling admins and  
customers in the same table. An extra column for specifying the  
“admin” role seems a waste for two or three admins vs thousands of  
customers. On the other hand, I don’t want to duplicate code. I know I  
can reduce this using mixins as quite a lot of the encryption  
functions would be the same, but still.

I’ve thought of two options. One, use polymorphic associations:

class Account \< ActiveRecord::Base  
belongs\_to :user, :polymorphic =\> true  
end

class Customer \< ActiveRecord::Base  
has\_one :account, :as =\> :user  
# customer attributes, address and orders associations  
end

class Administrator \< ActiveRecord::Base  
has\_one :account, :as =\> :user  
# extra admin attributes  
end

Or, two, have separate models and have the code look up the username/  
password combos from different database tables. The two user types  
wouldn’t know about each other.

Am I mad for separating out the logins? Or, does it make logical sense  
based on the fact that the models are filling two completely different  
roles.

Any advice gratefully received.

Thanks,  
Jordan

---

<div class="post-metadata">

**Author:** ![jordelver](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9dc877/32.png) [@jordelver](https://www.ruby-forum.com/u/jordelver)\
**Post date:** [August 6, 2007, 5:14pm UTC](https://www.ruby-forum.com/t/logins-for-customers-and-admins/111372/2 "2007-08-06T17:14:32Z")

</div>

Just use STI. It’ll keep things cleaner.

"On the one hand, I don’t like the idea of muddling admins and  
customers in the same table. An extra column for specifying the  
“admin” role seems a waste for two or three admins vs thousands of  
customers. "

NULL doesn’t take up any space. May be you can just have a roles  
table. That’ll be more scalable solution.

On 8/6/07, Jordan E. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> a couple of Administrators for the system and it’s likely to stay that
> 
> based on the fact that the models are filling two completely different  
> roles.
> 
> Any advice gratefully received.
> 
> Thanks,  
> Jordan
> 
> >

–  
Cheers!

- Pratik  
[http://m.onkey.org](http://m.onkey.org)

---

<div class="post-metadata">

**Author:** ![jordelver](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/9dc877/32.png) [@jordelver](https://www.ruby-forum.com/u/jordelver)\
**Post date:** [August 7, 2007, 8:34pm UTC](https://www.ruby-forum.com/t/logins-for-customers-and-admins/111372/3 "2007-08-07T20:34:45Z")

</div>

Hi,  
Thanks for reply.

> Just use STI. It’ll keep things cleaner.

Why do you think this method is cleaner?

> NULL doesn’t take up any space. May be you can just have a roles  
> table. That’ll be more scalable solution.

Good point. It’s not the space so much, it the mixing of two fairly  
unrelated models.  
The roles table is a obvious point which I didn’t think of 🙂

Cheers,  
Jordan