The fromDate as part of the PK is part of the effective date pattern,
and having the thruDate not be part of the PK is the same way. The
point is not to avoid duplication with a finely grained time slot, in
fact it should _NEVER_ be used to artificially distinguish (ie by
anything except time) one record from another. Never.
A general principle of data modeling is to use composite primary keys
whenever possible, especially for "join" tables. This is an important
part of the OFBiz data model. Only "primary" entities, ie those that
exist somewhat independently like Product, OrderHeader, Party, etc
should have sequenced IDs. Abusing those causes all sorts of
problems... and when you have hundreds of tables those problems
become extremely expensive to manage in a hurry.
-David
On Feb 27, 2006, at 6:05 PM, Chris Howe wrote:
> I have a question about using "fromDate" as part of a
> primary key. What benefit does having a timestamp in
> a primary key over creating an simple record key? The
> timestamp is so specific that it is highly unlikely to
> prevent duplicates.
>
> ie in BillingAccountRole the entity is:
>
> *billingAccountId
> *partyId
> *roleTypeId
> *fromDate
> thruDate
>
> why not just have:
>
> *billingAccountRoleId
> billingAccountId
> partyId
> roleTypeId
> fromDate
> thruDate
>
> _______________________________________________
> Dev mailing list
>
[hidden email]
>
http://lists.ofbiz.org/mailman/listinfo/dev
_______________________________________________
Dev mailing list
[hidden email]
http://lists.ofbiz.org/mailman/listinfo/dev