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.

• HectorLector: What if they change the ID? What if you want to use the same system to work with another external system, which uses different IDs? If there are no (performance) problems, I would go with strings.
• Blrfl: "And more often than not these identifiers are integers." - You still have to develop for the not cases,

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

• Pieter B: This is good, because it prevents things like "00123" being converted to 123. This is important because sometimes those leading zeroes are significant.
• JimmyJames: In general: it's not really a number if you can do math with it. e.g. postal codes, telephone numbers, street numbers, basically any Id.

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.

• Vilx-: Read the question again. This is about consuming IDs from an external system.
• Lewis Pringle: @Vix what part of what I said appears wrong with that? That you don't have control over the type of the external IDs (their format?). If you have no control, then I don't understand the point of the question. You must store the ids as they are defined externally.
• Lewis Pringle: @Vix - still - what I said (except for forcing the use of a particular format) is right anyhow. LOGICALLY treat them as strings. Compare them as binary blobs. Its more efficient to compare if you KNOW the size in advance and its fixed, but if the rules of your game prevent that - so be it.
• Ewan: "use GUIDs" is always good advice. regardless of the question