Is it right to use string when the value is integer?

Question

Today I came across a certain situation that left me in doubt:

In my application I have some ID's from a table, these ID's are integer values (1,2,3, and so on) and I treat them all as string.

One of the reasons I do this is not to use the method: Convert.Toint and I end up using the method : .ToString()

I will not perform any mathematical operation, it is only for identification of records (Primary key).

These ID's are obtained from a GridView populated by a DataTable which in turn has the data coming from the BD, those ID's are generated by the bank by a column with Identity then we’ll never have duplicate values.

Nor do I care if the value is first, last, which is next, is just to identify the record deletion action.

Is this treatment correct? what is the form indicated in these cases?

Answer 1

There is no correct or wrong itself in this case. There is the indicated and the most efficient. If the fields are integers, treat them as such. It may seem like you don’t have anything stopping you from using integers converted to string in this situation, but there is a "rule" in system development that I usually follow very successfully: Do the least surprising thing. Always.

Surprising, in this case, should be read as "something that generates less surprise".

In this case, if the field is whole (or long) in the database, treat it as such in your code as well. This will generate less surprise to some other programmer, or even to yourself when you come to solve a bug in the code a few years from now. Also, use Convert.ToInt32() in place of ToString() it will have no difference, but just the fact that you wonder if treating the whole as a string in your code is the right one, already shows that the ideal would be neither need to ask this question and treat whole as the whole that is.

I also assure you that in DataTable this field is integer. If you compare the Gridview ID with the id in the dataset/datatable, you may have to convert back to integer of any

There are still future features that may be affected by this unnecessary conversion made today. For example, you may need to put the Ids inside a Hashset and if they are strings the operations will be slower (not much, because Hashset uses a hash to be found, but there is a loss of performance). You may want to sort the Ids to know which one was created before in the database (since it is Identity) and the string ordering, in addition to much slower, does not follow the numerical order: "10" < "2" whereas 10 > 2.

In short: while there are reasons to use integer as integer, with advantages, there are no advantages or reasons (in your case) to treat them as string.

Don’t nail pieces to yourself (and others who use your code). Do what’s least surprising. Ask yourself: What’s the most expected? That an entire field in the database is treated as a string in your code, or that is treated as an integer?

Answer 2

Although you don’t use Ids for mathematical operations, you certainly do make comparisons, especially when searching for data in your database. With performance in mind, the best practice is still to use numbers, as comparisons can be made in one cycle, while string comparison requires each character to be compared (unless Voce converts to numbers). With respect to your concern to call Tostring repeatedly, you can rest assured, as this method is very fast and optimized at CLR level, so you will never be the Bottleneck in any application. What could be a problem and the Boxing and Unboxing of the values, ie, letting C# do the work for Voce.

For example, the code

for(int i = 0; i < 50; i++) {
    sb.Append(i.ToString()); 
    sb.Append(",");
}

is faster than

StringBuilder sb = new StringBuilder();
for(int i = 0; i < 50; i++) 
    sb.Append (i + ",");

Precisely because the second requires extra Boxing and Unboxing operations.

This way, it makes more sense to worry about the efficiency of the search in your bank and other comparisons between the Ids than with Tostring, which means that in general int would be a better choice.