How to store external numeric IDs - as strings or as integers?

Question

Every now and then we programmers need to communicate with external systems (not under our own control). It's frequent that in such cases we need to keep track of some sort of identifiers that these external systems use. And more often than not these identifiers are integers.

In such cases, should these external identifiers be preserved in our own systems as opaque strings (since they typically arrive as text in a JSON/XML); or maybe it's OK to store them as integers locally? Especially if that external ID is part of a classifier that you need to use often?

On the pro side, an integer would take less space and be overall more efficient. In addition, if there was some sort of error, it wouldn't be possible to insert a record with a non-numeric value.

On the con side, it's an external ID and there's nothing to say that they won't start at one point to add characters there too (like, when they do an upgrade and now there are extra values that are somehow different and they just append a letter when giving the IDs out so that there's no overlap with the old values).

My perfectionist side tells me to go for strings; my practical side says that integers will be a bit easier to deal with locally.

Answer 1

unless the datatype is specified then save it as the datatype it comes in.

so if you have json:

{
   "id" : 123
}

Then you know you can 'safely' save it as a 'number' of unspecified precision

if you get

{
   "id" : "123"
}

Then its a string, unless your external provider says "The Id field is a 32 bit int encoded as a string for transmission"

Really strings are no more difficult to handle than ints, go for the safe option unless you have a specific performance issue to address

Answer 2

Always as strings. Why? From experience, one day those external identifiers will come with letters in them, because the users of that external system asked for that enhancement.

Any user visible ID will sooner or later be taken over by user 'requirements', and then it loses some of its capabilities. User will want to specify, change, range-code, etc. , any IDs they see.

Answer 3

Use GUIDs (in all external APIs/systems). These can be treated as 'strings' or 'large-integers' internally depending on your language system. They can even be efficiently mapped to/from integers (having a separate mapping table) - for INTERNAL use in your system.

Thus you largely get to have your cake and eat it too: the safety of large string ids (guids), but the efficiency (almost) of short integer ids.