On 2/20/18 3:51 PM, Chris Angelico wrote:
On Wed, Feb 21, 2018 at 7:42 AM, Rick Johnson
<rantingrickjohn...@gmail.com> wrote:
On Tuesday, February 20, 2018 at 2:18:31 PM UTC-6, MRAB wrote:
The point he was making is that if you store a person's age, you'd have
to update it every year. It's far better to store the date of birth and
calculate the age on demand.
*AHEM*
At the risk of being labeled a "quibbler" (which, in the
grander scheme is not really all that bad considering some
of the names that have been attributed to me), i must say
your advice is only "sound advice" in cases where the age
will not be queried frequently.
For instance, if the age is queried many times a second, it
would be a much wiser design to set-up an event that will
advance the age at the end of the last second of every year,
instead of doing the age calculation many times a second.
Heck, even if the frequency is multiple time a day, a valid
argument could be made.
Nope. Even if you need the age many times per second, it's still
better to store the date of birth, because you eliminate boundary
conditions and duplicated data. But that's assuming you're storing the
age of *a person*. If the age in question is a boundary ("motor
insurance premiums are increased if the driver is 65 years or older"),
then it's still sane to store the age.
ChrisA
I would normally expect that the persistent store would have a birth
date of the person, but within a local operation, you likely want to be
able to assume the consistency of a attribute like over 55 years old, so
you would compute the age, for that operation, but not keep it beyond
that. Otherwise, depending on the order of doing your checks you may
find that during your processing they are either both or neither of
under 55 and over 55. It is much easier to reason that your code is
correct when you can prevent (and thus ignore) such data races. This
normally means your operation grabs the value of 'now' once, and all
processing will be based on THAT point of time, not what currently is
'now'. How big this 'timestop' needs to be depends on how wide the
requirement is for temporal consistency. It might be just within a
function, it might be for the full duration of the program run, 'now'
might even be a parameter to the program, i.e. as of last (or next)
midnight, do the computation.
--
Richard Damon
--
https://mail.python.org/mailman/listinfo/python-list
