To convert to accurate data types or maintain default type of string

Question

Scenario:
I have a web application that records and checks data against two temp tables (1 table being a temp source and the other being a destination for the application). These temp tables are synced up each night with their respective destination/source sql views.

The Issue:
The source/destination views have char/nvarchar data types however the actual content inside these views are mostly integers. How should I construct my model for the temp tables within the application; should I convert the data to their real types (converting the types during sync time) or just keep them in the form of strings?

Important:
There is no validation needed for the types, it will be impossible for the user to enter invalid data. The true data types of the content will hold constant for each column with no accidental variation. So the question comes down to, is there anything wrong with processing integers as strings? Other than it being annoying as hell.

Answer 1

Store them in the database as the respective data types. Instead of storing "1234" as a string, store the int 1234.

This does a couple of things for you.

1. It prevents data consumers from having to do the conversion and possible mistakes (not only will this prevent mistakes, but it'll maximize performance for the data consumers. Convert the data before it is dumped into the table so it doesn't have to be continuously converted upon retrieval)
2. It will allow bad data to fail fast and fail early, as you wouldn't be able to put bad data in the source table (i.e. on an int column, if you didn't expect bad data but attempted to throw "123a4" in there it would fail. That's a good thing)
3. Store the data as it is expected. It will alleviate a lot of complications.

Answer 2

There are tradeoffs to consider...

If the data will always remain integers, you might consider conversion to integers. But beware of predicting the future. If the data needs to be compared or sorted, or otherwise analyzed by range depending on the numeric value, then you might consider conversion to integers. If the data may need to be flexible with regard to formatting, you might consider keeping the strings.

Sometimes things that look like numbers end up needing some descriptive prefix or suffix added later, and that will break your conversions. If they are not really numeric values that mean anything, for instance they are simply identifiers, then they are much easier to deal with as strings. This gives you full flexibility in formatting them and you don't have to worry about numeric validity checking. You can trim the strings, validate the digits by their location within the string - the options are limitless.

Assume you have highway 70 in the database with 70 in the highway number column. You might have a direction column that can contain, NSEW values. What if you want to add Hwy "70 Alt" South? The "Alt" can't go in the direction column, yet it breaks the conversion of the highway number. The 70 in the highway number doesn't mean it is greater than highway 65 or less than highway 75. It should be a string both in the database and in your code.

A column that contains a specific mile marker on Hwy 70 should be a number, though.