Dev - Double posting in service and entity ECAs

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Dev - Double posting in service and entity ECAs

cjhowe
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
Reply | Threaded
Open this post in threaded view
|

Re: Dev - Double posting in service and entity ECAs

David E. Jones

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

smime.p7s (3K) Download Attachment