Chris,
Is this how OFBiz is currently doing things? I can see your point.
But currently, I have a limiting/crippling "time to market" constraint. When building for
flexibility, there can be no end to the quest. Whatever you said of Product IDs, the same may be
said of ProductFeature IDs or any other IDs in OFBiz. Usually, I'm forced to deliver the
application first, see how things run with prototype, then figure out where to go next after
getting a better view. I usually can't decide whether to construct a skyscraper on small plateau
or sprawling shopping mall on large plateau when I haven't even climbed up the plateau to see what
size it really is. Hindsight is cheaper to buy than foresight.
Still, back to your discussion with Product IDs. Can I use fields like "Internal Name" and
"Description" for my storefront? I know the storefront currently displays Product ID. This is a
real problem. I'd like a bit, even if just a tiny amount, of discussion or ideas thrown in at this
moment for this topic.
(To Boss: Any chance you'll be changing your Product IDs like Chris said?)
Jonathon
Chris Howe wrote:
This is "big picture" discussion and certainly not
cookie cutter, so there are pros and cons on both
sides. I take the approach that being the programmer,
you have the capability to provide your company or
your client's company the capability to not let
database theory requirements get in the way of them
running their business.
As far as making life easier, you can still do lookups
based on aliases and treat them as if they are unique,
as they certainly need to be unique for the date
(think getProductNameForDate service instead of
getPartyNameForDate). The burden should be placed on
the programmer to make this seamless, not on the
business to adjust to the peculiarities.
From a competitive perspective, the first potential
problem with using the automated intelligence
productId as the glue to hold together your different
product data is the scenario where a competitor comes
along, is more successful in gaining the mind share of
the sequence of the components for the intelligence
productId. Their 2KBL34M37 is the equivalent to your
B730HM250, but you carry a different product with ID
2KBL34M37. You're both in the same industry and
customers mistakenly order your competitors product Id
thinking that you are perhaps a distributor of their
product or them of yours.
Now no solution can prevent this from happening the
first time or even perhaps the tenth time. However
once you realize the problem, an intelligent primary
key prevents you from taking action without completely
overhauling your database and making assumptions about
your historical data which is perhaps inaccurate. An
alias primary key lets you come out with a "new"
product line renaming everything under the sun without
changing the underlying product data.
Just to provide a real world business story behind
this, productId naming conventions happen to be an
important consideration with me as I'm in an industry
where manufacturers consistently overlap their
productIds and brand names don't really get plastered
into the heads of the people ordering the product
(medical supplies). A hospital could be ordering a
"6002" and be meaning to order a diaper or they could
be meaning to order a cardiac catheter surgical prep
kit or a bone saw. Those three items from the
manufacturers perspective are in diverse enough fields
to never recognize that there is a conflict with
productId. However, down the supply chain a
distributor is handling all three and perhaps losing
sales for the manufacturer because of their inability
to clarify the end customer's needs.
You may not need to deal with these considerations
(much larger and successful companies have chosen not
to). But you should do yourself a favor and take the
short amount of time to consider it now and weigh that
against what you end up being locked into. It's no
skin off my nose if you decide the effort to implement
such a convention isn't worth the flexibility gained
later ( unless you're a medical supply manufacturer
:-) )
Regards,
Chris
