Optimization should only be done if it is really necessary. I doubt this optimization will pay off in any scenario.
The basic rule for selecting the type when they can be confused is what you will use them for. Numbers represent quantities. Are CPF or CNPJ amounts? No, they are identifiers that can even change, which may one day have letters. The correct semantics for this data is
varchar after all it is descriptive.
The question of zero left alone is good enough to use
varchar . Why bother playing a problem with the wrong type.
You should always opt for
varchar on any data until you find a reason to choose another type. A general ID, for example, has a good reason to be
int , it needs to be incremented, you make accounts with it. The same goes for salary, price, quantity. But not worth to zip code, earphone, even number of a property at address when this field is separate. A due date has to be of another type, you need to sort the information by date order, and as text this would not work correctly. Just a few examples.
Some even say that it is necessary to use
varchar because it has punctuation beyond numbers. But this is not a good argument since the score should not even be recorded, at least not in most situations. This should be resolved in the presentation only, the punctuation is not part of the data.
In some cases a numeric type can not be used since the number of digits used to identify something is larger than the numeric type it is.
Some will say that
varchar should not be used. Because the size is fixed, a simple
char solves the problem. But there is controversy about that. Depending on the DB system one type may actually be more advantageous than another but not enough to justify, in most cases, a choice because of performance. Semantics should be the primary choice.
Unfortunately there is a lot of wrong information on the internet about it (or any subject :)).