# Expired items

**URL:** <https://www.ruby-forum.com/t/expired-items/168707>\
**Category:** Rails\
**Created:** [May 24, 2009, 7:17pm UTC](https://www.ruby-forum.com/t/expired-items/168707 "2009-05-24T19:17:21Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![semyou](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ce7236/32.png) [@semyou](https://www.ruby-forum.com/u/semyou)\
**Post date:** [May 24, 2009, 7:17pm UTC](https://www.ruby-forum.com/t/expired-items/168707/1 "2009-05-24T19:17:21Z")

</div>

Hi guys,

I have a model Post which has a expiry\_date. I want to know what is the  
best way to manage scalability in this case. 2 options:

1. Whenever I want to SELECT from the table, I need to include where  
expiry\_date \> NOW. If the table Post grows like a monster, I will be in  
trouble. Imagine after 3 years or more. Indexes will be huge too.

2. Have a trigger, cron job, or a plugin (if it exists) that would go  
around the table and move expired items to a new table Post\_Archive.  
That way, I maintain only current Posts in my main table, which implies  
that over 3 years I won’t be as bad as option 1.

Any help? comments from your experience?

Thanks,  
Youssef

---

<div class="post-metadata">

**Author:** ![semyou](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ce7236/32.png) [@semyou](https://www.ruby-forum.com/u/semyou)\
**Post date:** [May 24, 2009, 8:20pm UTC](https://www.ruby-forum.com/t/expired-items/168707/2 "2009-05-24T20:20:41Z")

</div>

On May 24, 6:17 pm, Youyou S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
wrote:

> Hi guys,
> 
> I have a model Post which has a expiry\_date. I want to know what is the  
> best way to manage scalability in this case. 2 options:
> 
> 1. Whenever I want to SELECT from the table, I need to include where  
> expiry\_date \> NOW. If the table Post grows like a monster, I will be in  
> trouble. Imagine after 3 years or more. Indexes will be huge too.

You could have a table with millions of rows and such a query would be  
fast (as long of course as you had an index on the expiry\_date  
column). Not to say that moving expired posts somewhere else wouldn’t  
necessarily be a bad idea but certainly not something I would do  
preemptively

Fred

---

<div class="post-metadata">

**Author:** ![semyou](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ce7236/32.png) [@semyou](https://www.ruby-forum.com/u/semyou)\
**Post date:** [May 24, 2009, 10:38pm UTC](https://www.ruby-forum.com/t/expired-items/168707/3 "2009-05-24T22:38:31Z")

</div>

Youyou S. wrote:

> 1. Whenever I want to SELECT from the table, I need to include where  
> expiry\_date \> NOW. If the table Post grows like a monster, I will be in  
> trouble. Imagine after 3 years or more. Indexes will be huge too.

Obviously using indices is the easiest. I’m not sure how many posts  
you’re expecting, but unless you _know_ it’ll run into the millions with  
a high percentage of cache misses this sounds like premature  
optimization. First let your RDBMS deal with the size of the indices  
(it’ll do fine) and then let your DBA worry about it (he’ll cache it  
into RAM and put it on a fast disk).

–  
Roderick van Domburg  
[http://www.nedforce.com](http://www.nedforce.com)

---

<div class="post-metadata">

**Author:** ![semyou](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ce7236/32.png) [@semyou](https://www.ruby-forum.com/u/semyou)\
**Post date:** [May 25, 2009, 7:54pm UTC](https://www.ruby-forum.com/t/expired-items/168707/4 "2009-05-25T19:54:23Z")

</div>

Roderick van Domburg wrote:

> Youyou S. wrote:
> 
> > 1. Whenever I want to SELECT from the table, I need to include where  
> > expiry\_date \> NOW. If the table Post grows like a monster, I will be in  
> > trouble. Imagine after 3 years or more. Indexes will be huge too.
> 
> Obviously using indices is the easiest. I’m not sure how many posts  
> you’re expecting, but unless you _know_ it’ll run into the millions with  
> a high percentage of cache misses this sounds like premature  
> optimization. First let your RDBMS deal with the size of the indices  
> (it’ll do fine) and then let your DBA worry about it (he’ll cache it  
> into RAM and put it on a fast disk).
> 
> –  
> Roderick van Domburg  
> [http://www.nedforce.com](http://www.nedforce.com)

Thank you guys. You saved me a lot of work. I will not move them out of  
the table even though I know I am supposed to expect billions of rows if  
everything goes as expected!

Thanks,  
Youssef