Come memorizzare ID numerici esterni - come stringhe o come numeri interi?

3

Ogni tanto i programmatori devono comunicare con sistemi esterni (non sotto il nostro controllo). È frequente che in questi casi sia necessario tenere traccia di alcuni tipi di identificatori utilizzati da questi sistemi esterni. E il più delle volte questi identificatori sono interi.

In questi casi, questi identificatori esterni dovrebbero essere conservati nei nostri sistemi come stringhe opache (poiché tipicamente arrivano come testo in un JSON / XML); o forse è giusto memorizzarli come numeri interi localmente? Soprattutto se quell'ID esterno fa parte di un classificatore che devi usare spesso?

Dal lato pro, un intero richiederebbe meno spazio ed essere complessivamente più efficiente. Inoltre, se ci fosse un qualche tipo di errore, non sarebbe possibile inserire un record con un valore non numerico.

Dal lato degli attacchi, è un ID esterno e non c'è nulla da dire che non inizieranno a un certo punto per aggiungere personaggi anche lì (come quando fanno un aggiornamento e ora ci sono valori extra che sono in qualche modo diversi e aggiungono semplicemente una lettera quando danno gli ID in modo che non ci siano sovrapposizioni con i vecchi valori.

Il mio lato perfezionista mi dice di andare per archi; il mio lato pratico dice che gli interi saranno un po 'più facili da gestire localmente.

    
posta Vilx- 07.09.2018 - 13:46
fonte

3 risposte

8

a meno che non sia specificato il tipo di dati, salvalo come tipo di dati.

quindi se avete json:

{
   "id" : 123
}

Quindi sai che puoi "tranquillamente" salvarlo come un "numero" di precisione non specificato

se ottieni

{
   "id" : "123"
}

Quindi è una stringa, a meno che il tuo provider esterno non dica "Il campo Id è un 32 bit int codificato come stringa per la trasmissione"

In realtà le stringhe non sono più difficili da gestire di inte, scegli l'opzione sicura a meno che tu non abbia un problema di prestazioni specifico da affrontare

    
risposta data 07.09.2018 - 13:57
fonte
1

Sempre come stringhe. Perché? Dall'esperienza, un giorno quegli identificatori esterni arriveranno con delle lettere, perché gli utenti di quel sistema esterno hanno chiesto questo miglioramento.

Ogni ID visibile dell'utente verrà prima o poi preso in carico dai "requisiti" dell'utente, e quindi perderà alcune delle sue funzionalità. L'utente vorrà specificare, cambiare, codice di intervallo, ecc., Qualsiasi ID che vedono.

    
risposta data 07.09.2018 - 20:28
fonte
-5

Usa GUID (in tutte le API / sistemi esterni). Questi possono essere trattati internamente come "stringhe" o "interi di grandi dimensioni" in base al tuo sistema di lingua. Possono anche essere mappati in modo efficiente a / da interi (con una tabella di mappatura separata) - per l'uso INTERNO nel tuo sistema.

Così puoi avere la tua torta e mangiarla in gran parte: la sicurezza degli id di stringa di grandi dimensioni (guids), ma l'efficienza (quasi) degli ID di interi brevi.

    
risposta data 07.09.2018 - 15:27
fonte

Leggi altre domande sui tag