Comments on: Reduce Complexity with Self-Expiring Data Columns http://www.nodroidsallowed.com/2007/12/03/reduce-complexity-with-self-expiring-data/ Practical techniques for raising a well-adjusted database Tue, 17 Jan 2012 12:33:02 +0000 hourly 1 http://wordpress.org/?v=3.1.3 By: vdibart http://www.nodroidsallowed.com/2007/12/03/reduce-complexity-with-self-expiring-data/comment-page-1/#comment-8 vdibart Thu, 20 Dec 2007 15:41:02 +0000 http://www.nodroidsallowed.com/?p=6#comment-8 You are right - you will always need a background process if you want to perform some other action when it expires. This pattern doesn't address that issue, only the issue of whether you need a background process to actually do the expiring. But keep in mind that the background process itself can construct the query as outlined above. If you think about this for a while, you will realize that the pattern naturally ensures that you can rerun that process any number of times without harming data integrity. But that might be a topic for another post :) You are right – you will always need a background process if you want to perform some other action when it expires. This pattern doesn’t address that issue, only the issue of whether you need a background process to actually do the expiring. But keep in mind that the background process itself can construct the query as outlined above. If you think about this for a while, you will realize that the pattern naturally ensures that you can rerun that process any number of times without harming data integrity. But that might be a topic for another post :)

]]> By: charles http://www.nodroidsallowed.com/2007/12/03/reduce-complexity-with-self-expiring-data/comment-page-1/#comment-7 charles Thu, 20 Dec 2007 01:06:34 +0000 http://www.nodroidsallowed.com/?p=6#comment-7 Hey Vinny, thanks for the tip. This definitely sounds like the right method for self-expiring data. But I think you would still need a background process if you want to take action at the time of expiration (e.g. sending an email notification). Are there any other ways to do that? Hey Vinny, thanks for the tip. This definitely sounds like the right method for self-expiring data. But I think you would still need a background process if you want to take action at the time of expiration (e.g. sending an email notification). Are there any other ways to do that?

]]> By: vdibart http://www.nodroidsallowed.com/2007/12/03/reduce-complexity-with-self-expiring-data/comment-page-1/#comment-5 vdibart Thu, 06 Dec 2007 20:59:14 +0000 http://www.nodroidsallowed.com/?p=6#comment-5 If I understand you properly.....logically, I think this is the same as using just EXPIRES_TS. In other words: TTL + CREATE_TS = EXPIRES_TS So in effect this is an alternate formulation of the idea, and I think just as valid. One benefit I can think of is that you probably don't have to index TTL, so if you already have CREATE_TS indexed you're saving yourself on index space and upkeep. One drawback is that it's not very self-descriptive - the developer would have to know that TTL is applied to CREATE_TS, and not some other column like UPDATE_TS (which I always have in my tables....more on that later) Thanks for the suggestion though. If I understand you properly…..logically, I think this is the same as using just EXPIRES_TS. In other words:

TTL + CREATE_TS = EXPIRES_TS

So in effect this is an alternate formulation of the idea, and I think just as valid. One benefit I can think of is that you probably don’t have to index TTL, so if you already have CREATE_TS indexed you’re saving yourself on index space and upkeep. One drawback is that it’s not very self-descriptive – the developer would have to know that TTL is applied to CREATE_TS, and not some other column like UPDATE_TS (which I always have in my tables….more on that later)

Thanks for the suggestion though.

]]> By: Jason http://www.nodroidsallowed.com/2007/12/03/reduce-complexity-with-self-expiring-data/comment-page-1/#comment-4 Jason Thu, 06 Dec 2007 18:04:42 +0000 http://www.nodroidsallowed.com/?p=6#comment-4 Dog, What about a TTL column in conjunction with the CREATE_TS, instead of EXPIRED_TS? That would answer your homework problem of messages differing expiration times. If you wanted to change all messages that lived for ten days to twenty you wouldn't have to look at CREATE_TS to do so. Display code would add TTL to CREATE_TS and check against sysdate. would also improve performance the bulk update. There are pros and cons to this but I guess the only major advantage to the TTL way would be for clarity in the varying expiration logic. - Jason Dog,

What about a TTL column in conjunction with the CREATE_TS, instead of EXPIRED_TS? That would answer your homework problem of messages differing expiration times. If you wanted to change all messages that lived for ten days to twenty you wouldn’t have to look at CREATE_TS to do so. Display code would add TTL to CREATE_TS and check against sysdate. would also improve performance the bulk update. There are pros and cons to this but I guess the only major advantage to the TTL way would be for clarity in the varying expiration logic.

- Jason

]]>