[Babase] Storing male mature dates in the database
Daphne A. Onderdonk
babase@www.eco.princeton.edu
Tue, 23 Nov 2004 10:06:54 -0500
We talked with Jeanne and Karl about all of this when Karl was here, and
we realized there were some things we needed to go over with you,
Susan. Yes, it was my understanding that for Matured and Ranked we want
to have the 2 types - actual dates and matured/ranked by dates. But for
Consorted and Dispersed, do we need the "by" type, or do we just want
actual dates for those markers? The "by" type seemed less useful to me
for Consorted and Dispersed, but we thought we'd ask you.
Karl said he was envisioning a different table for each life history
marker, as individuals will only go into the table when they have
reached that marker.
Karl also said that the Matured table would include both males and
females. For females, I guess we wouldn't use the "matured by" type,
except maybe for the females who were mature at the beginning of the
study - we could use "matured by" for them. It was my understanding
that the Matured table was the only one of these tables that would
include females.
Daphne
Susan Alberts wrote:
>> On 2004.11.20 02:31 Susan Alberts wrote:
>>
>>> Works for me. The two columns would be called something like
>>> "matured" and "mature by", right? I am not attached to any
>>> particular name as long as it's clear. Thanks,
>>
>>
>> Uh, we want _one_ column, and a second 'type" column. The
>> type would indicate 'matured-natal' or 'matured by'.
>
>
>
> Oh right, sorry to be dense. Yes, I think this will work well.
>
> We will have to do this both for "matured" and for "ranked" --
> "matured" signals the entry to subadulthood, "ranked" to adulthood.
>
> Remind me, will there be separate tables for males and females? I
> can't remember what we discussed here. If both are in the same table,
> then all females and all natal males for whom we have the data will
> have one code, all males for whom we do not have the data (immigrant
> males who entered after maturity and natal males for whom we missed
> this event) will have another. Right?
>
> Another issue is that we used "ranked" as an indicator of adulthood
> for males and so it is quite an important marker for males. However,
> the same is not for females. For females we used "matured" to indicate
> the onset of adulthood. While we would, in principle, like to have
> "ranked" dates recorded for females, in practice we have not had this
> in the database, so this field has been blank for females. So for the
> "ranked" table we would only have males in it at least for now, yes?
> (I think I recall that we talked about separate tables for matured,
> ranked and consorted). The same would be true for consorted.
>
> Susan
>
>
>
>>
>>>
>>> Susan
>>>
>>>> Susan,
>>>>
>>>> After meeting with folks here the concensus is that
>>>> it's a bad idea to store "we're sure they're mature
>>>> by this date" male maturity dates in a different
>>>> table from the "we watched these males reach
>>>> maturity" mature dates. For lots of reasons,
>>>> mostly having to do with difficulty writing
>>>> queries to find all the adults if we have 2 tables, we think they
>>>> should go in the same table and be distinguished
>>>> by a 'kind of maturity date' flag.
>>>>
>>>> However, we have to convince you before going forward.
>>>>