I would also urge caution in changing keys. There is one advantage in using UUIDs. If you have distributed or replicated data, you can generate new rows in different locations and you can be sure there will be no collisions when you synchronize later on.
There are disadvantages to UUIDs too. Compactness matters in keys. An excessive key size means database index entries are big, and therefore less will fit in pages and there will be more disk I/O to search the index. UUIDs are random, so in tree indexes pages will be split at random, and there will be considerable fragmentation. In contrast, if the key is continually increasing, all the action is in the bottom right hand corner of a tree index, and (assuming the keys are stable and a low number of deletes) there won't be many random splits elsewhere. So UUIDs really only make sense if you have distributed or replicated data, and that's not typical for OFBiz. If you really wanted to use UUIDs, it might be possible to store them in binary form, where they would occupy 16 bytes (128 bits). Cheers Paul Foxworthy Mike Z wrote > This is certainly one way to do it. > > In my case, I prefer to use "SUPPLIER_ID-SUPPLIER_PN" for the PRODUCT_ID, > and use the same format for electronictext, contentid, contentassoc, etc. > It allows me to logically organize the product_id, and also allows me to > blow away a product if I need to. Example: > > product_id | product_type_id | primary_product_category_id > 10000-798936838421 | FINISHED_GOOD | 10003 | > > 10000-798936838421Dru | ELECTRONIC_TEXT | > | | | | > | ru | > > The above supplier "10000", and PN (UPC) is the PRODUCT_ID, and the above > ELECTRONIC_TEXT entry is the russian description (Dru) of the item. > > A sample similar to the above was in DemoData, so I went with it. > > On Wed, May 1, 2013 at 3:41 AM, Adrian Crum < > adrian.crum@ >> wrote: > >> >> On 4/30/2013 4:52 PM, Mike wrote: >> >>> Compare the following three files: >>> >>> framework/entity/fieldtype/**fieldtypemysql.xml >>> framework/entity/fieldtype/**fieldtypepostgres.xml >>> framework/entity/fieldtype/**fieldtypepostnew.xml >>> >>> I bet you are using mysql, or maybe even postgres, which has very >>> LIMITED >>> key value lengths. In the real world, you never know what key length >>> you >>> may need in the future, so why limit yourself? Now take a look at >>> "postnew", which uses a generic "text" type for almost all the fields. >>> It >>> allows ANY key length, which allows the flexibility to create logical >>> relations, even for part numbers that may be 60 characters or so. >>> >>> I learned this the hard way, when I came across long part numbers, and >>> struggled to figure out a way to logically store them. Back then I was >>> using mysql. >>> >> >> Part numbers are a GOOD IDENTIFICATION. So, you wouldn't put the part >> number in a 20 character ID field. Instead, you would use the standard ID >> sequence generator for the PRODUCT, then link the PRODUCT to a GOOD >> IDENTIFICATION. >> >> -Adrian >> >> ----- -- Coherent Software Australia Pty Ltd http://www.coherentsoftware.com.au/ Bonsai ERP, the all-inclusive ERP system http://www.bonsaierp.com.au/ -- View this message in context: http://ofbiz.135035.n4.nabble.com/Use-UUID-for-ProductID-tp4640950p4640971.html Sent from the OFBiz - User mailing list archive at Nabble.com.
