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 <
[email protected]> 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
>
>
