Genera un numero casuale a 4 cifre casuale da un altro numero a 4 cifre

Ci sono fondamentalmente diverse soluzioni a questo problema come lo hai presentato.

È possibile creare una mappatura veramente casuale dal numero A (ID privato) al numero B (ID pubblico) se si dispone di una fonte indipendente di casuale. Ogni volta che crei un'altra riga e ti viene assegnato il numero A letto da casuale e crei il numero B. Per garantire che B sia univoco, dovrai cercare tutti i B esistenti prima di assegnarlo. Questo sarebbe il modo più difficile per chiunque di decodificare. È fondamentalmente ciò che la crittografia chiama una volta sola. È anche sempre più proibitivo man mano che ti avvicini sempre più al popolamento completo dello spazio che hai consentito. Alla fine si arriva dove c'è solo 1 numero da assegnare come B. Devi aspettare di trovarlo a caso e devi cercare di dimostrare l'unicità in ogni tentativo.

Una trasformazione fissa del numero A in B mediante una funzione. Questo evita di diventare proibitivo anche quando si riempie completamente lo spazio. Rischia anche l'utente che indovina l'algoritmo. Questo può essere mitigato se invece di usare semplicemente un hash per fare ciò, si cripta il numero A. Esistono algoritmi di crittografia che producono il testo crittografico della stessa dimensione come testo semplice e prendono una crittografia (chiave). Fatto in questo modo non avrebbe importanza se avessero indovinato come hai creato B fintanto che la cryptovariable (chiave) era ancora un segreto. Vorresti utilizzare un formato che conserva la crittografia . Questo ti dà la possibilità di predire A da una B, ma se indichi B sul database questo non dovrebbe essere necessario.

Se ritieni che sia eccessivo, puoi guardare in uno shuffle che semplicemente offusca A. Questo rischierebbe di indovinare lo shuffle a meno che non utilizzasse anche una variabile crittografica.

Vale anche la pena considerare se A è ancora necessario. Se l'unica cosa che A fornisce è un identificativo univoco, non ha senso essere in grado di riconvertire in A e nessun motivo per memorizzare A nel database quando B è tutto ciò che è necessario. Ciò significa che tutto ciò che devi fare è unicamente randomizzare l'ID di incremento automatico perché questo ti darà B per iniziare. Alcuni DB lo forniscono già. In questo modo hai ID univoci che non predicono x o y ed evitano un livello di riferimento non necessario.

Considerando che:

• Il numero di ID è finito e piccolo (circa 2k righe in una tabella e 2k nell'altra tabella)
• L'"alias ID generato" deve essere composto da 4 numeri, il che significa che il numero di collisioni sarà troppo alto se si prova qualsiasi funzione di hash.

Quindi consiglio:

• precarica l'ID alias in un'altra colonna della stessa tabella, quindi non devi calcolarlo in tempo reale.

Ho creato questa soluzione utilizzando bash per creare le coppie, forse puoi replicare in un'altra lingua:

1. Ho creato un file contenente stringhe da 0000 a 4000

   $ seq -f "%04g" 0 4000 > /tmp/data.txt

2. Ho creato un secondo file con stringhe da 0000 a 9999 (questo sarà l'ID falso)

   $ seq -f "%04g" 0 9999 > /tmp/data2.txt

3. Ho codificato il secondo file:

   $ sort -U /tmp/data2.txt > /tmp/data3.txt

4. Ho troncato il file risultante esattamente alle prime 4001 righe

   $ head -n 4001 > /tmp/data4.txt

5. Poi ho associato tutti gli ID originali con i loro ID alias

   $ paste data.txt data4.txt > data5.txt

Dopodiché hai un file (data5.txt) che puoi usare per popolare entrambe le tue tabelle con l'ID sequenziale ed è un ID a 4 numeri casuali.

0000    3675
0001    2464
0002    1808
0003    9569
0004    3309
...
3996    9843
3997    7497
3998    7892
3999    3062
4000    5687