It is nice to have a primary key be descriptive, as it allows less programming thought and verification to go into an application. However that should be weighed against the dangers and limitations that convention may put on you. I don't think prodCatalogId or prodCategoryId, for that matter, have as many potential pitfalls as productId does, at least not in the limited ways they have been used thus far. Also, any convention used for a prodCatalogId or prodCategoryId can be discarded and not cause as large of a business interruption as changing a convention on productId might, I would imagine.
Tossing my 2 cents in since my name was invoked. :-) --- Jonathon -- Improov <[EMAIL PROTECTED]> wrote: > Hi Shi Yusen, > > You mentioned "prodCatalogId". That goes for all other fields of type > id-ne, including > Product.productId? > > I do agree that improvements need to be made incrementally, so we > don't have to wait say a decade > before we can start using the "corrected" OFBiz. As I told Chris, I'd > rather not have to > do/witness the painfully arduous task of creating say OFBiz version > "ERD Corrected". It works now > for me, and that's all I need (at least until I need to put chinese > characters into URLs for > lookups, but I'd use POST usually). > > I'm just curious why it was done that way, that's all. > > By the way, I was just thinking of importing data, and I realized I > wouldn't know the primary keys > when entering data for import if those keys were auto-incremented > integer ids. Is that why all > id fields are strings instead of integers? > > Maybe I'll dig into the data reader (that imports data from xml > files). What happens if my data > for import omits primary key values? > > Jonathon > > Shi Yusen wrote: > > Hi Jonathon, > > > >> I'm curious why Product.productId isn't a meaningless neutral > integer as prescribed by the Data > >> Model book. Chris Howe described some issues caused by using the > Product.productId under some > >> circumstances, and they seems closely related to this. > > I think ProductId is not discussed in this topic. There's an > implicit rule: as OFBiz is a productivity application, NO EFFICIENCY > of OFBiz should be lost when making any improvements :). Take it > easy. > > > > Regards, > > > > Shi Yusen/Beijing Langhua Ltd. > > > > > >
