I have a company code for the product that consists of two letters and four numbers (example: XX0000), it is advisable to use this code as the primary key or to create another column with a code field and put unique
to this code?
I have a company code for the product that consists of two letters and four numbers (example: XX0000), it is advisable to use this code as the primary key or to create another column with a code field and put unique
to this code?
Is this code unique and will never be changed for each line (entity)? If so, is a good candidate for primary key yes. Otherwise I would suggest using another, some artificial ( surrogate ), a id
of control internal database probably self-incrementing somehow.
Every primary key must be unique (and it does not accept nulls) and ideally it will never be changed (this is why CPF is a bad primary key, nothing guarantees that the person will have the same CPF forever, imagine email , telephone and the like).
Be careful because a lot of people think that a code will never be changed, but that is not always true, I've seen many situations that codes that would never change and once changed. Companies restructure the way they manipulate their products for a variety of reasons. This XX
is a worrier, because this has the face of being a classifier and classifications change, it is rare, but it changes. The problem is not having letters, the problem is the stability of the data.
You can even do different, but ideally primary keys should always be increasing. It has a database that it must be, this is not the case with MySQL.
I give a answer about myths about data .
If the field you are quoting fits in this situation, it may be a primary key.
Only one caveat: This field in XX0000 format will be represented by varchar
in your bank. Perhaps using a numeric field to represent the primary key ( an auto-increment column, for example ) would yield better performance, but would have to be evaluated. If so, you could make your field a unique key
to avoid duplication of values.