# Lookup tables

**URL:** <https://www.ruby-forum.com/t/lookup-tables/105330>\
**Category:** Rails\
**Created:** [May 28, 2007, 10:09pm UTC](https://www.ruby-forum.com/t/lookup-tables/105330 "2007-05-28T22:09:25Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![railskater](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/3ab097/32.png) [@railskater](https://www.ruby-forum.com/u/railskater)\
**Post date:** [May 28, 2007, 10:09pm UTC](https://www.ruby-forum.com/t/lookup-tables/105330/1 "2007-05-28T22:09:25Z")

</div>

It is interesting to think about traditional db “lookup” tables in  
rails. Consider the notion of a “stage.” A stage can be “active”,  
“suspended”, “completed”, “terminated”, etc. In rails thinking I would  
have some object models which happen to be “stageable” (polymorphic  
associations). Example: an employee could be stageable (employee could  
have many stages- each stage has a stage type). Obviously, the  
“stage\_type” model is the traditional lookup table.

Maybe I lack proper understanding but I tend to fear the “find(:all…)”  
method because I am thinking in terms of thousands of rows. I want to  
return a list of objects which have some “stage” in the lookup table  
(with some other conditions). But why do I have to load the whole  
collection?

I mean it seams like I am forced to load that whole collection and then  
do operations on the collection to group them by stage type (the lookup  
table). Then I would have to extract the grouped subset.

Is there not a better way? I am trying to think about it without  
resorting to a new join model (since I don’t know how I would  
parameterize the join model for the different values in the lookup  
table).

Can anyone help straighten my wayward thinking?

Thanks,

---

<div class="post-metadata">

**Author:** ![railskater](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/3ab097/32.png) [@railskater](https://www.ruby-forum.com/u/railskater)\
**Post date:** [May 28, 2007, 11:33pm UTC](https://www.ruby-forum.com/t/lookup-tables/105330/2 "2007-05-28T23:33:21Z")

</div>

If I was doing this I would just have a table stage and a :belongs\_to  
for each object that can have stages. Then you can query any table on  
its stage or set of stages in a single query. If you are wanting all  
objects of any type in a stage then things get very messy as you  
indicated because you are navigating from the stage using a  
polymorphic association. In general though that seems overkill.  
Generally I want things grouped or filtered by stage not all objects  
regardless of type in a stage.

Michael

On May 28, 1:09 pm, Philip D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)

---

<div class="post-metadata">

**Author:** ![railskater](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/3ab097/32.png) [@railskater](https://www.ruby-forum.com/u/railskater)\
**Post date:** [May 29, 2007, 8:41am UTC](https://www.ruby-forum.com/t/lookup-tables/105330/3 "2007-05-29T08:41:37Z")

</div>

Thanks, MichaelLatta, for your input. I still think I am not  
understanding Rails filtering and finders at a very deep level. Yes it  
is easy to filter simple models using the built in finder methods. When  
using these methods with simple tables, I feel like I am working in the  
object oriented methodology. However, when there are more objects (like  
employees and stages) I feel like the finders and filtering methods do  
loose their object oriented feeling. Why? They do not provide access  
to anything but the one model you started with. As soon as I decide to  
use the find methods for the Employee object then I immediately have no  
search level access to the “other” objects owned by Employee instances.

Thanks for being patient. I simply want to understand how to do  
filtering and “finding” by using object oriented “style” only (and not  
using SQL and also without the complete table being loaded into a  
collection).