> Each table has the following fields as a minimum: > id > date_learn_start * Optional To manage only on "what you know" .. > date_learn_end * .. remove any date_learn stuff from the explenation > below > date_effect_start > date_effect_end > > You would not use auto incrementing id fields, you would need a > sequence to be able to issue unique ids.
Yeah, that's pretty much the way I've seen it done as well. Depending on the implementation, I'm thinking you may only need one effective date field - the date_effect_start. The application behavior would then have to make the assumption that a 'newer' record automatically outdates the old one. Eg: id date ----- ------------------- 1 12/16/05 1 05/31/06 The application could assume that the first incarnation is effective from 12/16/05 through 05/31/06. The second incarnation is then effective from 05/31/06 until now. This has the added benefits of 1) consisting of fewer writes, 2) storing less data, 3) preventing 'effective date overlap' based on flawed application logic or code failure. I'm sure there's a downside but I can't think of it now ... > Anyway, HTH, > > AD7six It does help, thanks for thinking this through with me. I was just hoping there might be a more graceful way for Cake to handle data aging other than through my chickenscratch code :) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Cake PHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
