Is there an acceptable standard within the industry for defect tracking numbering?
The reason I ask is that a client has asked for a defect tracking database for each different Product (ie. Product A bug #'s 1 - nth, Product B bug #'s 1 - nth, etc). Furthermore, they have asked if Defects and Issues can also be numbered differently (ie. Product A bug # 1 - nth, issue # 1 - nth).
All I see this doing is complicating the situation and causing a lot of redundancy.
Please don't take this the wrong way, just imagine my smile as you read it out loud. "I believe the industry standard to be the auto-increment field on the table". Note I said "believe".
I have to agree with you that might create redundancy if all the projects are tracked in the same database. But, since you mentioned they want a different database for each one, you might ask why they would need a different numbering system. Maybe a suggestion to the client to allow the system to number the defects and include the Product/Project name in any reports and views. They may not be thinking far enough ahead to see that would be the most efficient way to handle this. Of course if you are building the system, you could give them what they want by concatenating the fields on the report and in the views and still keep it simple by letting the table create the numbers .
Most bug tracking systems should allow you to create separate modules for each product that you want to track. So that will give you independent numbering for each product starting from 1. The last thing that I thought you would have wanted was for bugs for product A and product B to be intermingled in the same system, which seems to be what you would prefer?
As for tracking bugs and issues separately, if doesn't seem like a good idea as you then have 2 different places to look in to find the information relating to a single product, and people will get confused as to whether they are logging a bug or an issue. A better solution would be to use a field in the bug report (eg., status) to distinguish between the types, this way it is very easy to change an entry from one type to another. However, if that is what you client wants then it can be easily achieved by having 2 modules, eg., Product A - bugs and Product A - issues.