Inserimento di dati all'interno di ID, buona idea?

Questa è una domanda molto ampia e non hai dichiarato molte delle cose che avrei bisogno di sapere per dirti cosa è meglio e cosa no. Ma qui ci sono cose da considerare:

1. È obbligatorio che tutti gli identificatori siano globalmente unici? Chi possiede e fa rispettare lo spazio dei nomi? Incorporando la fonte dell'ID, puoi rendere più semplice garantire l'univocità, poiché ogni origine ha il proprio mini-namespace.

2. La dimensione dell'identificatore è importante? Ovviamente, un identificatore più lungo occupa più spazio e può essere più difficile da cercare in determinate strutture di dati, ad es. un indice DB, che sarà in grado di contenere un numero inferiore di identificatori per pagina indice.

3. Gli identificatori sono a prova di manomissione? Cambiando la parte dei dati dell'ID, un hacker potrebbe fare un pacchetto fare qualcosa che normalmente non dovrebbe fare?

4. Gli identificatori sono ipotizzabili? Scegliendo altri ID, un hacker potrebbe fare qualcosa di nefasto? Introducendo una porzione di dati nell'ID, potresti ridurre la sua entropia.

5. Hai dei requisiti per la compatibilità in avanti o all'indietro?

6. Come vengono trasmessi gli ID? Esiste un set di caratteri limitato o qualcosa deve codificare o fuggire?

7. L'ID corrente è completamente numerico e stai proponendo di aggiungere caratteri non numerici? Gli ID non numerici sono più vulnerabili agli attacchi di iniezione.

8. Ci sono dei requisiti per la varietàbility?

Ti sto rispondendo dal punto di vista degli sviluppatori di database. In generale, la procedura migliore consiste nell'utilizzare un numero intero sequenziale per un ID. Il motivo principale sono le prestazioni, ovvero il modo in cui il database taglia i dati quando si inserisce (pagina e cluster o qualcosa del genere). Un DBA può dirti di più. Inoltre, dal punto di vista commerciale, la codifica dei dati aziendali in un ID è quasi sempre una cattiva idea. Si incontrano problemi durante l'ordinamento e la partecipazione, ecc. Basta creare una nuova proprietà sul proprio oggetto aziendale. Questo è quello per cui sono lì. Gli ID sono lì per identificare.

Se vuoi aggiungere qualcosa agli ID che potrebbero fungere da filtro dai dati errati probabilmente sarebbe meglio includere ad esempio. ultimi 4 caratteri di sha1 o md5 dell'ID + sale stesso, quindi non possono essere facilmente fabbricati.

Ma penso, tuttavia, che inviare questi dati "checksum" come un altro parametro sarebbe meglio. Quindi puoi inviare ID + checksum e scartare il checksum nel processo, o almeno salvarlo al di fuori dell'ID in modo da non aggiungere dati inutili a una chiave indicizzata, poiché tutti i dati che hai inserito sono costosi dal DB prospettiva. La cosa migliore sarebbe se fornissi qualche campione di dati.

L'altra parte della tua domanda è interessante ... perché dici che ridisegnerai la tua applicazione in parte a causa del modello di prezzo di AWS, mentre per $ 90 al mese puoi ottenere un server con 32 GB di RAM, 8 core e mezzo TB di archiviazione SSD. È bello pagare per la tranquillità se hai soldi e vuoi lavorare su qualcosa che "funziona" ... ma se hai paura dei costi, penso che sarebbe molto meglio dal tuo punto di vista investire il tempo trascorso dal trasloco di AWS, perché il rapporto prezzo / prestazioni è così ridicolo che i costi ti uccideranno a lungo termine. Per me questi ambienti cloud condivisi sono sempre un fattore limitante, lento, costoso, con software scadente e vecchio installato e con un prezzo da bandwidtch pazzesco.

Voglio dire se puoi avere milioni di richieste al secondo su un server che non costa nulla, pensare ad ogni richiesta su AWS è uno spreco di vita, che puoi sprecare per es. progettando nuove funzionalità per la tua app ... e oltre a non avere senso, non diventerà economico, non importa quanto tu castrassi il codice, comprimi la comunicazione, ecc. sarebbe comunque costoso come HELL per qualsiasi cosa tranne un'app che non ha traffico;)