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. >
