Stepping back for a second...
The workflow I have been considering is this...
I would have a simple Administrator page where the left side of the webpage displays all current SKU's (i.e. Products). There would be some filtering mechanism (e.g. drop-down menus) to reduce the SKU's being shown as there could be ten of thousands.
Maybe I would select the design "Nom Nom" and the left side of the page would show me this...
Which basically means that I have the "Nom Nom" design in T-Shirts (i.e. "TS") for Men and Women (i.e. "M" and "F"), in White and Black (i.e. "01", "02"), in Small, Medium, and Large (i.e. "SM", "MD", "LG").
Knowing this, maybe we would want to add Red as a color for just Men's T-Shirts.
So seeing our current inventory of "Nom Nom" shirts, I would then go to the right half of the Administrative webpage, and I would choose Design = "Nom Nom" (1001), Style = "Men's T-Shirt" (TSM), Color = "Red" (03), Size = "Small" (SM) from the drop down boxes.
This would build a the SKU...
The system would verify that such a SKU does not already exist.
And after clicking "Create SKU", the system would INSERT a new record in the Products table with a primary key = "1001-TSM-03-SM" and the corresponding other fields filled out.
I would repeat this process and next create a similar Medium and Large shirt.
This may seem like a rather laborious process, but - as I see it - would allow us to "tweak" our inventory to match what people are buying. (Since most Americans are soooo F-A-T, it might turn out we never sell "Small" shirts?! Or maybe it turns out that females tend not to buy "Red" shirts for whatever reason.)
When we first populate the Products table, I would likely just use a spreadsheet to quickly create a large number of combinations we think will sell, but moving forward, what I described above would give control to the Administrator.
Does that make sense?
Does "dynamically creating SKUs" make sense based on what I described above?
Is there anyway I could get into trouble with the database (and data integrity) doing what I described?
So there is no problem adding all those hyphens into a Primary Key field?
Why do you think that having 3 extra hyphens is not extraneous or breaking any rules?
(It seems okay as long as it doesn't freak out the database like spaces do, but I know when someone once asked that question in years past on a Microsoft usergroup, the resident "gurus" flipped out?!)
Just trying to better understand the mechanics of why it is or is not okay.
P.S. You are a man of few words, r937!!!!