Discussion: Potential Data Model Improvements
Locked
12
12
Discussion: Potential Data Model Improvements
 
|
I'm writing this to start a thread to discuss: If you could change ANYTHING in the OFBiz data model, what would it be? To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... -David ======================================================== - Rename *Role entities to *Party - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) - Remove all status history (*Status) and just using audit on the statusId field - ProductPrice add quantity breaks, change PK to single field sequenced - Get rid of QuantityBreak and use the two simple fields instead in each place used - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced - Change Quote to be other types of Order - Make Return more like Invoice (ie no adjustment, just use items for everything) - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere - PartyRelationship simplify (single sequenced ID) - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType - Move most *Type entities to Enumeration values (update seed data, referring entities, remove *Type) (after this remove all remaining hasTable fields) - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem - Review use of Appl, Assoc (look at book, make sure consistent) - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) - Change GoodIdentification to ProductIdentification - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) - Get rid of NoteData, put noteText very-long field directly on various *Note entities - Review all entities with large PKs (esp 4+ fields) - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field - CustRequest to Request - FinAccount to FinancialAccount - Invoice handle recurrence? (was using RecurrenceInfo) - Get rid of optional ProductFeature concept (conf/etc products much better model) - Instead of various *Term entities and mapping, just use OrderTerm everywhere - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc - Agreement - make price list easier/cleaner - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) - Product clean up: move dimenstions to new entity, remove content fields, etc - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure |
Re: Discussion: Potential Data Model Improvements
|
|
On Mar 19, 2011, at 11:33 PM, David E Jones wrote: > > I'm writing this to start a thread to discuss: > > If you could change ANYTHING in the OFBiz data model, what would it be? > > To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... > > -David > > ======================================================== > > > - Move most *Type entities to Enumeration values (update seed data, referring > entities, remove *Type) (after this remove all remaining hasTable fields) Related to this: - Add the enumTypeId to the entity definition for the field <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ... Also, - Make userLoginId an ID that isn't changed, add a field for "name" that can be updated - Condense credit card name fields (first, middle, last, prefix, suffix, etc.) into a single "nameOnCard" |
Re: Discussion: Potential Data Model Improvements
|
|
On Mar 20, 2011, at 10:02 AM, Joe Eckard wrote: > > On Mar 19, 2011, at 11:33 PM, David E Jones wrote: > >> >> I'm writing this to start a thread to discuss: >> >> If you could change ANYTHING in the OFBiz data model, what would it be? >> >> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... >> >> -David >> >> ======================================================== >> >> >> - Move most *Type entities to Enumeration values (update seed data, referring >> entities, remove *Type) (after this remove all remaining hasTable fields) > > Related to this: > > - Add the enumTypeId to the entity definition for the field > > <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ... That's an interesting idea, make the framework aware of the EnumerationTypes... What I'm thinking of instead would be to use a convention, basically have the relation(ship).@title attribute be the enumTypeId (and use CamelCasing for the enumTypeIds). > Also, > > - Make userLoginId an ID that isn't changed, add a field for "name" that can be updated Yeah, that's a good idea. I like it enough that I just changed Moqui to work that way. Right now OFBiz has a work-around for changing usernames by creating a new UserLogin record and attaching it to the same Party. Since most stuff in the system records by party this works okay, but it's true that there is still a lot of stuff attached to the userLoginId that wouldn't be carried over, so this approach you're talking about is clearly better. > - Condense credit card name fields (first, middle, last, prefix, suffix, etc.) into a single "nameOnCard" This one I'm not so sure about. The OFBiz CreditCard entity actually started out with a single field for the name on card (and one for the company name on card), and then we ran into a problem where certain payment processors ask for separate first/middle/last names, and splitting based on spaces is not reliable (especially for those with multiple last names, etc). Is there are particular reason you've found the separated fields annoying? -David |
Re: Discussion: Potential Data Model Improvements
|
|
On Mar 21, 2011, at 2:34 AM, David E Jones wrote: > > On Mar 20, 2011, at 10:02 AM, Joe Eckard wrote: > >> >> On Mar 19, 2011, at 11:33 PM, David E Jones wrote: >> >>> >>> I'm writing this to start a thread to discuss: >>> >>> If you could change ANYTHING in the OFBiz data model, what would it be? >>> >>> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... >>> >>> -David >>> >>> ======================================================== >>> >>> >>> - Move most *Type entities to Enumeration values (update seed data, referring >>> entities, remove *Type) (after this remove all remaining hasTable fields) >> >> Related to this: >> >> - Add the enumTypeId to the entity definition for the field >> >> <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ... > > That's an interesting idea, make the framework aware of the EnumerationTypes... > > What I'm thinking of instead would be to use a convention, basically have the relation(ship).@title attribute be the enumTypeId (and use CamelCasing for the enumTypeIds). > That would work also, anything that would let you determine the type to look for. When I was building a generic entity editor in wicket, not being able to determine this programmatically was a big problem. >> Also, >> >> - Make userLoginId an ID that isn't changed, add a field for "name" that can be updated > > Yeah, that's a good idea. I like it enough that I just changed Moqui to work that way. > > Right now OFBiz has a work-around for changing usernames by creating a new UserLogin record and attaching it to the same Party. Since most stuff in the system records by party this works okay, but it's true that there is still a lot of stuff attached to the userLoginId that wouldn't be carried over, so this approach you're talking about is clearly better. > > >> - Condense credit card name fields (first, middle, last, prefix, suffix, etc.) into a single "nameOnCard" > > This one I'm not so sure about. The OFBiz CreditCard entity actually started out with a single field for the name on card (and one for the company name on card), and then we ran into a problem where certain payment processors ask for separate first/middle/last names, and splitting based on spaces is not reliable (especially for those with multiple last names, etc). > You're right, I didn't look into the other payment processors. I've worked with several large ones in the past and they all either didn't use the name, or accepted a single name field and I was concerned about the re-assembled name not matching what someone could have entered as a single string. > Is there are particular reason you've found the separated fields annoying? > > -David > > |
Re: Discussion: Potential Data Model Improvements
|
In reply to this post by David E. Jones-2
Sure, this would certainly improve things, but we need an upgrade path
and conversion programs. Further we need a version number related to the entity because the 'old' pattern does not do so well when there are several versions in the system: 'old', 'older' oldest'? Regards, Hans On Sat, 2011-03-19 at 21:33 -0600, David E Jones wrote: > I'm writing this to start a thread to discuss: > > If you could change ANYTHING in the OFBiz data model, what would it be? > > To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... > > -David > > ======================================================== > > - Rename *Role entities to *Party > - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) > - Remove all status history (*Status) and just using audit on the statusId field > - ProductPrice add quantity breaks, change PK to single field sequenced > - Get rid of QuantityBreak and use the two simple fields instead in each place used > - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store > - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced > - Change Quote to be other types of Order > - Make Return more like Invoice (ie no adjustment, just use items for everything) > - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere > - PartyRelationship simplify (single sequenced ID) > > - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc > - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType > - Move most *Type entities to Enumeration values (update seed data, referring > entities, remove *Type) (after this remove all remaining hasTable fields) > - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem > - Review use of Appl, Assoc (look at book, make sure consistent) > - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) > - Change GoodIdentification to ProductIdentification > - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) > - Get rid of NoteData, put noteText very-long field directly on various *Note entities > - Review all entities with large PKs (esp 4+ fields) > - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field > - CustRequest to Request > - FinAccount to FinancialAccount > - Invoice handle recurrence? (was using RecurrenceInfo) > - Get rid of optional ProductFeature concept (conf/etc products much better model) > - Instead of various *Term entities and mapping, just use OrderTerm everywhere > - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc > - Agreement - make price list easier/cleaner > - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) > - Product clean up: move dimenstions to new entity, remove content fields, etc > - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure > > -- Ofbiz on twitter: http://twitter.com/apache_ofbiz Myself on twitter: http://twitter.com/hansbak Antwebsystems.com: Quality services for competitive rates. |
Re: Discussion: Potential Data Model Improvements
|
|
The point is not how, the point is what. -David On Mar 22, 2011, at 12:43 AM, Hans Bakker wrote: > Sure, this would certainly improve things, but we need an upgrade path > and conversion programs. > > Further we need a version number related to the entity because the 'old' > pattern does not do so well when there are several versions in the > system: 'old', 'older' oldest'? > > Regards, > Hans > > > On Sat, 2011-03-19 at 21:33 -0600, David E Jones wrote: >> I'm writing this to start a thread to discuss: >> >> If you could change ANYTHING in the OFBiz data model, what would it be? >> >> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... >> >> -David >> >> ======================================================== >> >> - Rename *Role entities to *Party >> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) >> - Remove all status history (*Status) and just using audit on the statusId field >> - ProductPrice add quantity breaks, change PK to single field sequenced >> - Get rid of QuantityBreak and use the two simple fields instead in each place used >> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store >> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced >> - Change Quote to be other types of Order >> - Make Return more like Invoice (ie no adjustment, just use items for everything) >> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere >> - PartyRelationship simplify (single sequenced ID) >> >> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc >> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType >> - Move most *Type entities to Enumeration values (update seed data, referring >> entities, remove *Type) (after this remove all remaining hasTable fields) >> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem >> - Review use of Appl, Assoc (look at book, make sure consistent) >> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) >> - Change GoodIdentification to ProductIdentification >> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) >> - Get rid of NoteData, put noteText very-long field directly on various *Note entities >> - Review all entities with large PKs (esp 4+ fields) >> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field >> - CustRequest to Request >> - FinAccount to FinancialAccount >> - Invoice handle recurrence? (was using RecurrenceInfo) >> - Get rid of optional ProductFeature concept (conf/etc products much better model) >> - Instead of various *Term entities and mapping, just use OrderTerm everywhere >> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc >> - Agreement - make price list easier/cleaner >> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) >> - Product clean up: move dimenstions to new entity, remove content fields, etc >> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure >> >> > > -- > Ofbiz on twitter: http://twitter.com/apache_ofbiz > Myself on twitter: http://twitter.com/hansbak > Antwebsystems.com: Quality services for competitive rates. > |
Re: Discussion: Potential Data Model Improvements
|
|
In reply to this post by David E. Jones-2
Thanks David,
they are all good points; here are a few more from my wish list: - Remove TechData* entities and use WorkEffort - get rid of all the different GlAccount Default mappings entities and design a cleaner and central entity - move return type from the return item and to the header - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification - instead of OrderItemShipGrpInvRes we could use InventoryItemDetail (expanded) Kind regards, Jacopo On Mar 20, 2011, at 4:33 AM, David E Jones wrote: > > I'm writing this to start a thread to discuss: > > If you could change ANYTHING in the OFBiz data model, what would it be? > > To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... > > -David > > ======================================================== > > - Rename *Role entities to *Party > - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) > - Remove all status history (*Status) and just using audit on the statusId field > - ProductPrice add quantity breaks, change PK to single field sequenced > - Get rid of QuantityBreak and use the two simple fields instead in each place used > - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store > - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced > - Change Quote to be other types of Order > - Make Return more like Invoice (ie no adjustment, just use items for everything) > - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere > - PartyRelationship simplify (single sequenced ID) > > - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc > - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType > - Move most *Type entities to Enumeration values (update seed data, referring > entities, remove *Type) (after this remove all remaining hasTable fields) > - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem > - Review use of Appl, Assoc (look at book, make sure consistent) > - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) > - Change GoodIdentification to ProductIdentification > - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) > - Get rid of NoteData, put noteText very-long field directly on various *Note entities > - Review all entities with large PKs (esp 4+ fields) > - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field > - CustRequest to Request > - FinAccount to FinancialAccount > - Invoice handle recurrence? (was using RecurrenceInfo) > - Get rid of optional ProductFeature concept (conf/etc products much better model) > - Instead of various *Term entities and mapping, just use OrderTerm everywhere > - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc > - Agreement - make price list easier/cleaner > - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) > - Product clean up: move dimenstions to new entity, remove content fields, etc > - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure > > |
|
|
In reply to this post by J. Eckard-2
I agree with Joe on making the userLoginId a "system ID" and allowing the
user to change their userName. This would work a like the current partyId. We would still require the userName to be unique but it could be changed without impact so many other tables. Brett On Sun, Mar 20, 2011 at 10:02 AM, Joe Eckard <[hidden email]>wrote: > > On Mar 19, 2011, at 11:33 PM, David E Jones wrote: > > > > > I'm writing this to start a thread to discuss: > > > > If you could change ANYTHING in the OFBiz data model, what would it be? > > > > To kick this off here are some ideas I've compiled that have come up over > the years (many based on feedback from people on this mailing list), or that > I thought of recently will working on this topic. You can see them below... > > > > -David > > > > ======================================================== > > > > > > - Move most *Type entities to Enumeration values (update seed data, > referring > > entities, remove *Type) (after this remove all remaining hasTable > fields) > > Related to this: > > - Add the enumTypeId to the entity definition for the field > > <field name="locationTypeEnumId" enum-type="FACLOC_TYPE" ... > > Also, > > - Make userLoginId an ID that isn't changed, add a field for "name" that > can be updated > > - Condense credit card name fields (first, middle, last, prefix, suffix, > etc.) into a single "nameOnCard" > > > |
Re: Discussion: Potential Data Model Improvements
|
|
In reply to this post by Jacopo Cappellato-4
+1 On WorkEffort redesign.
+1 On PartyClassification redesign. On 3/22/2011 5:27 AM, Jacopo Cappellato wrote: > Thanks David, > > they are all good points; here are a few more from my wish list: > > - Remove TechData* entities and use WorkEffort > - get rid of all the different GlAccount Default mappings entities and design a cleaner and central entity > - move return type from the return item and to the header > - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification > - instead of OrderItemShipGrpInvRes we could use InventoryItemDetail (expanded) > > Kind regards, > > Jacopo > > On Mar 20, 2011, at 4:33 AM, David E Jones wrote: > >> I'm writing this to start a thread to discuss: >> >> If you could change ANYTHING in the OFBiz data model, what would it be? >> >> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... >> >> -David >> >> ======================================================== >> >> - Rename *Role entities to *Party >> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) >> - Remove all status history (*Status) and just using audit on the statusId field >> - ProductPrice add quantity breaks, change PK to single field sequenced >> - Get rid of QuantityBreak and use the two simple fields instead in each place used >> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store >> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced >> - Change Quote to be other types of Order >> - Make Return more like Invoice (ie no adjustment, just use items for everything) >> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere >> - PartyRelationship simplify (single sequenced ID) >> >> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc >> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType >> - Move most *Type entities to Enumeration values (update seed data, referring >> entities, remove *Type) (after this remove all remaining hasTable fields) >> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem >> - Review use of Appl, Assoc (look at book, make sure consistent) >> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) >> - Change GoodIdentification to ProductIdentification >> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) >> - Get rid of NoteData, put noteText very-long field directly on various *Note entities >> - Review all entities with large PKs (esp 4+ fields) >> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field >> - CustRequest to Request >> - FinAccount to FinancialAccount >> - Invoice handle recurrence? (was using RecurrenceInfo) >> - Get rid of optional ProductFeature concept (conf/etc products much better model) >> - Instead of various *Term entities and mapping, just use OrderTerm everywhere >> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc >> - Agreement - make price list easier/cleaner >> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) >> - Product clean up: move dimenstions to new entity, remove content fields, etc >> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure >> >> |
Re: Discussion: Potential Data Model Improvements
Administrator
|
In reply to this post by David E. Jones-2
I don't see any problems but one question inline
BTW, I think BJ would have loved that :o) Jacques David E Jones wrote: > I'm writing this to start a thread to discuss: > > If you could change ANYTHING in the OFBiz data model, what would it be? > > To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this > mailing list), or that I thought of recently will working on this topic. You can see them below... > > -David > > ======================================================== > > - Rename *Role entities to *Party > - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) > - Remove all status history (*Status) and just using audit on the statusId field > - ProductPrice add quantity breaks, change PK to single field sequenced > - Get rid of QuantityBreak and use the two simple fields instead in each place used > - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store Rename ProdCatalog* to ProductStoreCategory (only 1 entity?) and add field for an association with store? > - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced > - Change Quote to be other types of Order > - Make Return more like Invoice (ie no adjustment, just use items for everything) > - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere > - PartyRelationship simplify (single sequenced ID) > > - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc > - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType > - Move most *Type entities to Enumeration values (update seed data, referring > entities, remove *Type) (after this remove all remaining hasTable fields) > - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem > - Review use of Appl, Assoc (look at book, make sure consistent) > - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) > - Change GoodIdentification to ProductIdentification > - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) > - Get rid of NoteData, put noteText very-long field directly on various *Note entities > - Review all entities with large PKs (esp 4+ fields) > - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just > for a field > - CustRequest to Request > - FinAccount to FinancialAccount > - Invoice handle recurrence? (was using RecurrenceInfo) > - Get rid of optional ProductFeature concept (conf/etc products much better model) > - Instead of various *Term entities and mapping, just use OrderTerm everywhere > - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc > - Agreement - make price list easier/cleaner > - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) > - Product clean up: move dimenstions to new entity, remove content fields, etc > - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure |
Re: Discussion: Potential Data Model Improvements
|
|
On Mar 26, 2011, at 8:33 AM, Jacques Le Roux wrote: > I don't see any problems but one question inline > BTW, I think BJ would have loved that :o) > > Jacques > > David E Jones wrote: >> I'm writing this to start a thread to discuss: >> >> If you could change ANYTHING in the OFBiz data model, what would it be? >> >> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this >> mailing list), or that I thought of recently will working on this topic. You can see them below... >> >> -David >> >> ======================================================== >> >> - Rename *Role entities to *Party >> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) >> - Remove all status history (*Status) and just using audit on the statusId field >> - ProductPrice add quantity breaks, change PK to single field sequenced >> - Get rid of QuantityBreak and use the two simple fields instead in each place used >> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store > > Rename ProdCatalog* to ProductStoreCategory (only 1 entity?) and add field for an association with store? It wasn't "Rename ..." it was get rid of all of the ProdCatalog* entities and use a single ProductStoreCategory entity instead. The concept of "catalogs" always seems to have been confusing for people, and serves little purpose. There are also issues with the cart when switching catalogs, etc. The new ProductStoreCategory entity would be based on the ProdCatalogCategory entity, but associate various categories directly with the store instead of going through a catalog. -David |
Re: Discussion: Potential Data Model Improvements
|
|
In reply to this post by Jacopo Cappellato-4
On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: > Thanks David, > > they are all good points; here are a few more from my wish list: > > - Remove TechData* entities and use WorkEffort Yeah, that's a good idea that would simplify the data model and make things more flexible (though make the manufacturing scheduling code somewhat more complex). > - get rid of all the different GlAccount Default mappings entities and design a cleaner and central entity As a start we could at least move all of these entities to the accounting component (ie put them all in a single package, and in a single file). If we consolidate various of these to a single entity would we use a generic related key column? It's always a bummer to lose foreign keys, but there are quite a few entities that follow the same pattern and it certainly could be simplified... > - move return type from the return item and to the header Yes, this is a mess of bad design, we have: ReturnHeaderType ReturnItemType ReturnReason ReturnType IMO ReturnItem.returnTypeId should go to returnResponseEnumId (since it's really where the response is selected, and not a type for the return or the return item... at all), ReturnHeader.returnHeaderTypeId -> returnTypeEnumId, ReturnItem.returnItemTypeId -> itemTypeEnumId (use the shared item types mentioned in another item below to consolidate these so the same set are used for OrderItem, OrderAdjustment, InvoiceItem, ReturnItem, RequestItem, QuoteItem (irrelevant if/when Order* entities are used for quotes) > - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification Yes, this is another good one. This the pattern I had in mind: <entity entity-name="PartyClassification" package-name="mantle.party.party"> <field name="partyClassificationId" type="id" is-pk="true"/> <field name="classificationTypeEnumId" type="id"/> <field name="parentClassificationId" type="id"/> <field name="description" type="text-long"/> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> <key-map field-name="classificationTypeEnumId"/> </relationship> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> <key-map field-name="parentClassificationId"/> </relationship> </entity> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> <field name="partyId" type="id" is-pk="true"/> <field name="partyClassificationId" type="id" is-pk="true"/> <field name="fromDate" type="date-time" is-pk="true"/> <field name="thruDate" type="date-time"/> <relationship type="one" related-entity-name="Party"/> <relationship type="one" related-entity-name="PartyClassification"/> </entity> > - instead of OrderItemShipGrpInvRes we could use InventoryItemDetail (expanded) This one I'm not sure about. I like the idea of changing "OrderItemShipGrpInvRes" to just InventoryReserveration and moving it to the product.inventory package, but the InventoryItemDetail entity is used to keep a history of changes to the quantities/etc on an InventoryItem and the reservation records are created and removed as needed for the actual reservations needed, so I'm not sure it would be a good fit. -David > > Kind regards, > > Jacopo > > On Mar 20, 2011, at 4:33 AM, David E Jones wrote: > >> >> I'm writing this to start a thread to discuss: >> >> If you could change ANYTHING in the OFBiz data model, what would it be? >> >> To kick this off here are some ideas I've compiled that have come up over the years (many based on feedback from people on this mailing list), or that I thought of recently will working on this topic. You can see them below... >> >> -David >> >> ======================================================== >> >> - Rename *Role entities to *Party >> - Remove *Attribute and *TypeAttr entities (not generally a good practice to use) >> - Remove all status history (*Status) and just using audit on the statusId field >> - ProductPrice add quantity breaks, change PK to single field sequenced >> - Get rid of QuantityBreak and use the two simple fields instead in each place used >> - Get rid of ProdCatalog*, rework it to ProductStoreCategory, ie directly associate to the store >> - Change OrderItemShipGrpInvRes to InventoryReservation, change PK to single field sequenced >> - Change Quote to be other types of Order >> - Make Return more like Invoice (ie no adjustment, just use items for everything) >> - Instead of OrderItemType, OrderAdjustmentType, InvoiceItemType, ReturnItemType just use Shared ItemType everywhere >> - PartyRelationship simplify (single sequenced ID) >> >> - Make prefixes consistent (no suffixes), ie toPartyId instead of partyIdTo, etc >> - Change all relationships to PartyRole to be type one-nofk; use plain one for Party and RoleType >> - Move most *Type entities to Enumeration values (update seed data, referring >> entities, remove *Type) (after this remove all remaining hasTable fields) >> - Rework PhysicalInventory and InventoryVariance to simplify, reduce dependency on InventoryItem >> - Review use of Appl, Assoc (look at book, make sure consistent) >> - Add PartyIdentification entity, get rid of various fields and other entities (maybe even PartyTaxAuthority...) >> - Change GoodIdentification to ProductIdentification >> - Combine PartyContactMechPurpose and PartyContactMech (remove, only use entity with purpose, name PartyContactMech) >> - Get rid of NoteData, put noteText very-long field directly on various *Note entities >> - Review all entities with large PKs (esp 4+ fields) >> - Review and do something with all createOn/By lastUpdateOn/By fields, maybe add an auditing flag for the entity instead of just for a field >> - CustRequest to Request >> - FinAccount to FinancialAccount >> - Invoice handle recurrence? (was using RecurrenceInfo) >> - Get rid of optional ProductFeature concept (conf/etc products much better model) >> - Instead of various *Term entities and mapping, just use OrderTerm everywhere >> - Cleanup/reorg ShipmentCostEstimate, CarrierShipmentMethod, etc, etc >> - Agreement - make price list easier/cleaner >> - Remove all createdDate, createdByUserLogin, lastModifiedDate, lastModifiedByUserLogin fields (use framework defaults, audit-log) >> - Product clean up: move dimenstions to new entity, remove content fields, etc >> - Trim down big entities like Product, WorkEffort, etc; for groups of similar fields use a more normalized structure >> >> > |
Re: Discussion: Potential Data Model Improvements
|
|
Why can't we use the pattern in the Data Model Resource book? It's
simple and it works. -Adrian On 3/26/2011 9:57 AM, David E Jones wrote: > On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification > Yes, this is another good one. This the pattern I had in mind: > > <entity entity-name="PartyClassification" package-name="mantle.party.party"> > <field name="partyClassificationId" type="id" is-pk="true"/> > <field name="classificationTypeEnumId" type="id"/> > <field name="parentClassificationId" type="id"/> > <field name="description" type="text-long"/> > <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> > <key-map field-name="classificationTypeEnumId"/> > </relationship> > <relationship type="one" title="Parent" related-entity-name="PartyClassification"> > <key-map field-name="parentClassificationId"/> > </relationship> > </entity> > <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> > <field name="partyId" type="id" is-pk="true"/> > <field name="partyClassificationId" type="id" is-pk="true"/> > <field name="fromDate" type="date-time" is-pk="true"/> > <field name="thruDate" type="date-time"/> > <relationship type="one" related-entity-name="Party"/> > <relationship type="one" related-entity-name="PartyClassification"/> > </entity> > |
Re: Discussion: Potential Data Model Improvements
|
|
Could you be more specific? -David On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote: > Why can't we use the pattern in the Data Model Resource book? It's simple and it works. > > -Adrian > > > On 3/26/2011 9:57 AM, David E Jones wrote: >> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification >> Yes, this is another good one. This the pattern I had in mind: >> >> <entity entity-name="PartyClassification" package-name="mantle.party.party"> >> <field name="partyClassificationId" type="id" is-pk="true"/> >> <field name="classificationTypeEnumId" type="id"/> >> <field name="parentClassificationId" type="id"/> >> <field name="description" type="text-long"/> >> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> >> <key-map field-name="classificationTypeEnumId"/> >> </relationship> >> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> >> <key-map field-name="parentClassificationId"/> >> </relationship> >> </entity> >> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> >> <field name="partyId" type="id" is-pk="true"/> >> <field name="partyClassificationId" type="id" is-pk="true"/> >> <field name="fromDate" type="date-time" is-pk="true"/> >> <field name="thruDate" type="date-time"/> >> <relationship type="one" related-entity-name="Party"/> >> <relationship type="one" related-entity-name="PartyClassification"/> >> </entity> >> |
Re: Discussion: Potential Data Model Improvements
|
|
A PartyClassification ties a Party to a PartyType and it includes from
and thru dates (Figure 2.3 and Table 2.3). If you want to group classifications, then you group PartyType, not PartyClassification. -Adrian On 3/29/2011 9:48 AM, David E Jones wrote: > Could you be more specific? > > -David > > > On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote: > >> Why can't we use the pattern in the Data Model Resource book? It's simple and it works. >> >> -Adrian >> >> >> On 3/26/2011 9:57 AM, David E Jones wrote: >>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification >>> Yes, this is another good one. This the pattern I had in mind: >>> >>> <entity entity-name="PartyClassification" package-name="mantle.party.party"> >>> <field name="partyClassificationId" type="id" is-pk="true"/> >>> <field name="classificationTypeEnumId" type="id"/> >>> <field name="parentClassificationId" type="id"/> >>> <field name="description" type="text-long"/> >>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> >>> <key-map field-name="classificationTypeEnumId"/> >>> </relationship> >>> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> >>> <key-map field-name="parentClassificationId"/> >>> </relationship> >>> </entity> >>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> >>> <field name="partyId" type="id" is-pk="true"/> >>> <field name="partyClassificationId" type="id" is-pk="true"/> >>> <field name="fromDate" type="date-time" is-pk="true"/> >>> <field name="thruDate" type="date-time"/> >>> <relationship type="one" related-entity-name="Party"/> >>> <relationship type="one" related-entity-name="PartyClassification"/> >>> </entity> >>> |
Re: Discussion: Potential Data Model Improvements
|
|
Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book. Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field? -David On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote: > A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3). > > If you want to group classifications, then you group PartyType, not PartyClassification. > > -Adrian > > On 3/29/2011 9:48 AM, David E Jones wrote: >> Could you be more specific? >> >> -David >> >> >> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote: >> >>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works. >>> >>> -Adrian >>> >>> >>> On 3/26/2011 9:57 AM, David E Jones wrote: >>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification >>>> Yes, this is another good one. This the pattern I had in mind: >>>> >>>> <entity entity-name="PartyClassification" package-name="mantle.party.party"> >>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>> <field name="classificationTypeEnumId" type="id"/> >>>> <field name="parentClassificationId" type="id"/> >>>> <field name="description" type="text-long"/> >>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> >>>> <key-map field-name="classificationTypeEnumId"/> >>>> </relationship> >>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> >>>> <key-map field-name="parentClassificationId"/> >>>> </relationship> >>>> </entity> >>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> >>>> <field name="partyId" type="id" is-pk="true"/> >>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>> <field name="fromDate" type="date-time" is-pk="true"/> >>>> <field name="thruDate" type="date-time"/> >>>> <relationship type="one" related-entity-name="Party"/> >>>> <relationship type="one" related-entity-name="PartyClassification"/> >>>> </entity> >>>> |
Re: Discussion: Potential Data Model Improvements
|
|
Yes, we have been over this before, and no, I'm not forgetting anything
about the PartyType entity. Look at the PartyType demo data - what does it contain? It contains party classification types. Whether the PartyEntity was originally intended to follow the book's model or not, the truth is it is being used to store party classification types. If that is the case, then why do we need another entity that does the same thing? Yes, PartyClassification would be a join entity. I haven't looked at the impact on the Party.partyTypeId field - that is certainly worth discussing. -Adrian On 3/29/2011 10:58 AM, David E Jones wrote: > Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book. > > Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field? > > -David > > > On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote: > >> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3). >> >> If you want to group classifications, then you group PartyType, not PartyClassification. >> >> -Adrian >> >> On 3/29/2011 9:48 AM, David E Jones wrote: >>> Could you be more specific? >>> >>> -David >>> >>> >>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote: >>> >>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works. >>>> >>>> -Adrian >>>> >>>> >>>> On 3/26/2011 9:57 AM, David E Jones wrote: >>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification >>>>> Yes, this is another good one. This the pattern I had in mind: >>>>> >>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party"> >>>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>>> <field name="classificationTypeEnumId" type="id"/> >>>>> <field name="parentClassificationId" type="id"/> >>>>> <field name="description" type="text-long"/> >>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> >>>>> <key-map field-name="classificationTypeEnumId"/> >>>>> </relationship> >>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> >>>>> <key-map field-name="parentClassificationId"/> >>>>> </relationship> >>>>> </entity> >>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> >>>>> <field name="partyId" type="id" is-pk="true"/> >>>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>>> <field name="fromDate" type="date-time" is-pk="true"/> >>>>> <field name="thruDate" type="date-time"/> >>>>> <relationship type="one" related-entity-name="Party"/> >>>>> <relationship type="one" related-entity-name="PartyClassification"/> >>>>> </entity> >>>>> |
Re: Discussion: Potential Data Model Improvements
|
|
Hmmmm.... PartyType has the following data in OFBiz: <PartyType description="Automated Agent" hasTable="N" parentTypeId="" partyTypeId="AUTOMATED_AGENT"/> <PartyType description="Person" hasTable="Y" parentTypeId="" partyTypeId="PERSON"/> <PartyType description="Party Group" hasTable="Y" parentTypeId="" partyTypeId="PARTY_GROUP"/> <PartyType description="Informal Group" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="INFORMAL_GROUP"/> <PartyType description="Family" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="FAMILY"/> <PartyType description="Team" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="TEAM"/> <PartyType description="Legal Organization" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="LEGAL_ORGANIZATION"/> <PartyType description="Corporation" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="CORPORATION"/> <PartyType description="Government Agency" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="GOVERNMENT_AGENCY"/> Those don't look at ALL like the classifications mentioned in the book. The book mentions classification types such as "Income" and the actual classification would be something like "$20K-$40K". How is "$20K-$40K" like "Family"? I still have no idea where you're going with this... and I feel like as like as you respond with vague generalizations it's going to take a LOT of me responding with details to make up for that. -David On Mar 29, 2011, at 12:08 PM, Adrian Crum wrote: > Yes, we have been over this before, and no, I'm not forgetting anything about the PartyType entity. > > Look at the PartyType demo data - what does it contain? It contains party classification types. Whether the PartyEntity was originally intended to follow the book's model or not, the truth is it is being used to store party classification types. If that is the case, then why do we need another entity that does the same thing? > > Yes, PartyClassification would be a join entity. I haven't looked at the impact on the Party.partyTypeId field - that is certainly worth discussing. > > -Adrian > > > On 3/29/2011 10:58 AM, David E Jones wrote: >> Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book. >> >> Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field? >> >> -David >> >> >> On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote: >> >>> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3). >>> >>> If you want to group classifications, then you group PartyType, not PartyClassification. >>> >>> -Adrian >>> >>> On 3/29/2011 9:48 AM, David E Jones wrote: >>>> Could you be more specific? >>>> >>>> -David >>>> >>>> >>>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote: >>>> >>>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works. >>>>> >>>>> -Adrian >>>>> >>>>> >>>>> On 3/26/2011 9:57 AM, David E Jones wrote: >>>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >>>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification >>>>>> Yes, this is another good one. This the pattern I had in mind: >>>>>> >>>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party"> >>>>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>>>> <field name="classificationTypeEnumId" type="id"/> >>>>>> <field name="parentClassificationId" type="id"/> >>>>>> <field name="description" type="text-long"/> >>>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> >>>>>> <key-map field-name="classificationTypeEnumId"/> >>>>>> </relationship> >>>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> >>>>>> <key-map field-name="parentClassificationId"/> >>>>>> </relationship> >>>>>> </entity> >>>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> >>>>>> <field name="partyId" type="id" is-pk="true"/> >>>>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>>>> <field name="fromDate" type="date-time" is-pk="true"/> >>>>>> <field name="thruDate" type="date-time"/> >>>>>> <relationship type="one" related-entity-name="Party"/> >>>>>> <relationship type="one" related-entity-name="PartyClassification"/> >>>>>> </entity> >>>>>> |
Re: Discussion: Potential Data Model Improvements
|
|
Party classifications can be used in a number of ways - marketing
campaigns and employee classifications are two uses that come to mind. So, I could have a marketing campaign that targets families and therefore includes the "Family" party classification. Another marketing campaign might target corporations, so it would include the "Corporation" party classification. How am I being vague? I have cited the book, and in the previous discussion I gave a very detailed use-case scenario that demonstrated how the current model doesn't work and the book's model works. Maybe you could spend some time going over that thread again. Where am I going with this? As the thread's subject says, I'm discussing data model improvements. -Adrian On 3/29/2011 11:27 AM, David E Jones wrote: > Hmmmm.... PartyType has the following data in OFBiz: > > <PartyType description="Automated Agent" hasTable="N" parentTypeId="" partyTypeId="AUTOMATED_AGENT"/> > <PartyType description="Person" hasTable="Y" parentTypeId="" partyTypeId="PERSON"/> > <PartyType description="Party Group" hasTable="Y" parentTypeId="" partyTypeId="PARTY_GROUP"/> > <PartyType description="Informal Group" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="INFORMAL_GROUP"/> > <PartyType description="Family" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="FAMILY"/> > <PartyType description="Team" hasTable="N" parentTypeId="INFORMAL_GROUP" partyTypeId="TEAM"/> > <PartyType description="Legal Organization" hasTable="N" parentTypeId="PARTY_GROUP" partyTypeId="LEGAL_ORGANIZATION"/> > <PartyType description="Corporation" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="CORPORATION"/> > <PartyType description="Government Agency" hasTable="N" parentTypeId="LEGAL_ORGANIZATION" partyTypeId="GOVERNMENT_AGENCY"/> > > Those don't look at ALL like the classifications mentioned in the book. The book mentions classification types such as "Income" and the actual classification would be something like "$20K-$40K". > > How is "$20K-$40K" like "Family"? > > I still have no idea where you're going with this... and I feel like as like as you respond with vague generalizations it's going to take a LOT of me responding with details to make up for that. > > -David > > > On Mar 29, 2011, at 12:08 PM, Adrian Crum wrote: > >> Yes, we have been over this before, and no, I'm not forgetting anything about the PartyType entity. >> >> Look at the PartyType demo data - what does it contain? It contains party classification types. Whether the PartyEntity was originally intended to follow the book's model or not, the truth is it is being used to store party classification types. If that is the case, then why do we need another entity that does the same thing? >> >> Yes, PartyClassification would be a join entity. I haven't looked at the impact on the Party.partyTypeId field - that is certainly worth discussing. >> >> -Adrian >> >> >> On 3/29/2011 10:58 AM, David E Jones wrote: >>> Yeah, I think we've been over this before. You're still forgetting that the *Type entities in OFBiz have NOTHING to do with anywhere the term "type" is used in the Data Model Resource Book. >>> >>> Stepping back and allowing that this may not be the case, how would you imagine this model would look? Are you talking about PartyClassification being a join entity between Party and PartyType? What about the Party.partyTypeId field? >>> >>> -David >>> >>> >>> On Mar 29, 2011, at 11:01 AM, Adrian Crum wrote: >>> >>>> A PartyClassification ties a Party to a PartyType and it includes from and thru dates (Figure 2.3 and Table 2.3). >>>> >>>> If you want to group classifications, then you group PartyType, not PartyClassification. >>>> >>>> -Adrian >>>> >>>> On 3/29/2011 9:48 AM, David E Jones wrote: >>>>> Could you be more specific? >>>>> >>>>> -David >>>>> >>>>> >>>>> On Mar 29, 2011, at 10:24 AM, Adrian Crum wrote: >>>>> >>>>>> Why can't we use the pattern in the Data Model Resource book? It's simple and it works. >>>>>> >>>>>> -Adrian >>>>>> >>>>>> >>>>>> On 3/26/2011 9:57 AM, David E Jones wrote: >>>>>>> On Mar 22, 2011, at 6:27 AM, Jacopo Cappellato wrote: >>>>>>>> - redesign following a more standard approach PartyClassificationGroup/PartyClassificationType/PartyClassification >>>>>>> Yes, this is another good one. This the pattern I had in mind: >>>>>>> >>>>>>> <entity entity-name="PartyClassification" package-name="mantle.party.party"> >>>>>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>>>>> <field name="classificationTypeEnumId" type="id"/> >>>>>>> <field name="parentClassificationId" type="id"/> >>>>>>> <field name="description" type="text-long"/> >>>>>>> <relationship type="one" title="PartyClassificationType" related-entity-name="Enumeration"> >>>>>>> <key-map field-name="classificationTypeEnumId"/> >>>>>>> </relationship> >>>>>>> <relationship type="one" title="Parent" related-entity-name="PartyClassification"> >>>>>>> <key-map field-name="parentClassificationId"/> >>>>>>> </relationship> >>>>>>> </entity> >>>>>>> <entity entity-name="PartyClassificationAppl" package-name="mantle.party.party"> >>>>>>> <field name="partyId" type="id" is-pk="true"/> >>>>>>> <field name="partyClassificationId" type="id" is-pk="true"/> >>>>>>> <field name="fromDate" type="date-time" is-pk="true"/> >>>>>>> <field name="thruDate" type="date-time"/> >>>>>>> <relationship type="one" related-entity-name="Party"/> >>>>>>> <relationship type="one" related-entity-name="PartyClassification"/> >>>>>>> </entity> >>>>>>> |
Re: Discussion: Potential Data Model Improvements
|
In reply to this post by David E. Jones-2
Status History
--------------------- I can see the sense in having one repository for all change tracking. We just need to bear in mind there are more use cases for using the information in the repository than “auditing”. Auditing is a security activity, and it will be security professionals looking at a history of who did what. Looking at a status history could well be a business activity with no security dimension to it. So viewing the history of changes to an order’s status might be something a manager would do. We would need to structure permissions so that people who need some of the information for business purposes can use it even though they are not security professionals. The other thing to observe is that status history is currently *on* by default in Ofbiz, and auditing is *off* by default. QuantityBreak --------------------- No, don’t get rid of the QuantityBreak entity, and it should be used as part of pricing. Many organisations will have standard QuantityBreaks that apply to a wide range of products. An organization might want to offer various agreed prices to customers, but use the same quantity breaks consistently. It should be possible to add a new price for a product without having to define quantity breaks, with the risk that the newly entered quantity breaks are inconsistent with standard organisation policy. Purchase and Sales Agreements ----------------------------------------------- - the AgreementItem has the currency for prices. The currency should be on individual AgreementProductAppls. It should be possible to have agreed prices in various currencies for a product - AgreementProductAppl should have its own from and thru dates. A particular price might have a different timespan than the Agreement or (in the case of a purchase agreement) the SupplierProduct. You could imagine an agreement spanning a year with a list of special prices, each of which is available for one month - There’s no way at present to have a quantity break associated with an agreed price for a sales agreement. Quantity breaks are currently within the SupplierProduct entity, so are available for purchase agreements, but not sales agreements. SupplierProduct ----------------------- - As David says, a five-attribute primary key is unwieldy. It should be replaced with a simple ID. - SupplierProduct has a minimumQuantity attribute, so must be read in combination with other SupplierProducts. SupplierProduct should *not* have any information on quantity breaks. There should be just one instance of SupplierProduct to record that a product can be obtained from a supplier. A SupplierProduct should have associated QuantityBreaks and ProductPrices, as described in the Data Model Resource Book. - lastPrice in SupplierProduct is used both for the last price we obtained the product, and an agreed price. These are two separate things. Given the lastPrice might have been determined by an agreement that has expired, and by a quantity that we are not ordering this time, it's not very useful. It ought to be possible to determine the most recent prices we paid at various quantity breaks for a given product from a given supplier TaxAuthorityRateProduct ------------------------------------- - This entity is used to determine tax on shipping and promotional pricing adjustments, when these are not products. There should be a separate entity for tax on all order adjustments, which will determine tax based on the adjustment type rather than on the product category - The ProductStore is used to determine the tax payable. That’s fine for sales, but makes no sense for purchases. Really, the ProductStore is a proxy for the geo of the seller. TaxAuthorityRateProduct should be revised to list the geo of the seller rather than the ProductStore, then the same rules could be used by purchases as well as sales. For a sale, the ProductStore geo would be used as the geo of the seller.
--
Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |