Progettazione di database di indirizzi internazionali: campi, valori grezzi e controllo delle versioni

Input separato, componenti analizzati e output renderizzato

L'input non elaborato costituisce una prova, i campi analizzati supportano la ricerca e la logica aziendale e le righe visualizzate seguono l'ordine dei paesi. Mantenerne solo uno impedisce controlli successivi e aggiornamenti del parser.

Memorizza rawAddressLines, parsedComponents, normalizedAddress e il provider/versione di normalizzazione. Un errore di normalizzazione non dovrebbe distruggere la registrazione grezza.

Gli identificatori che sembrano numerici sono ancora testo

I codici postali e i numeri civici possono contenere zeri iniziali, lettere, spazi, trattini e intervalli. I tipi interi perdono dati e impongono patch specifiche del paese.

Utilizza il testo Unicode ovunque. Deriva i limiti di lunghezza da set di dati reali e confini aziendali, non da campioni inglesi medi.

type PostalAddress = {
  countryCode: string;
  addressLines: string[];
  adminArea1?: string;
  adminArea2?: string;
  adminArea3?: string;
  locality?: string;
  postalCode?: string;
  rawAddress: unknown;
};

Non mescolare stringhe vuote, null e mancanti

Definisce se una seconda riga assente viene omessa, nulla o vuota, quindi normalizza al limite. Altrimenti le query, la deduplicazione e le esportazioni trattano uno stato come tre.

Non riempire mai le righe mancanti con N/A o un trattino; i segnaposto si insinuano nelle etichette.

Utilizza istantanee per ordini e record di controllo

Una voce della rubrica può cambiare, mentre un ordine o una fattura devono conservare il loro indirizzo storico. Fare riferimento solo a addressId corrente modifica la cronologia.

Linee, componenti, stato di verifica e timestamp renderizzati dell'istantanea.

• Gli ordini non cambiano con la rubrica
• Registra il provider e la versione del normalizzatore
• Stato di verifica del timestamp
• Non registrare inutilmente indirizzi reali completi

Verifica le migrazioni con fixture di più paesi

Fixture di andata e ritorno contenenti locali con nome nel Regno Unito, codice postale alfanumerico canadese, Unicode tedesco, testo di origine giapponese e zeri iniziali. Confronta i campi semantici e JSON non elaborato, non solo il conteggio delle righe.

Una prova di migrazione dovrebbe contare i valori troncati, gli errori di decodifica e le modifiche da stringa vuota a nulla. Il successo del database non è sufficiente se l'applicazione non riesce a ricostruire le righe originali dopo averle rilette. Produci una differenza strutturale tra i vecchi e i nuovi record e prepara un percorso di riproduzione dai dati rawAddress conservati per trasformazioni irreversibili.

Esegui questa suite sia su un database di test pulito che su una copia ripulita degli schemi a forma di produzione. Indici realistici, vincoli e valori null legacy spesso rivelano comportamenti che uno schema vuoto ideale non è in grado di riprodurre.

Misura il percorso di lettura dell'applicazione e il processo di migrazione. Un serializzatore ORM, un indice di ricerca, una cache o un'esportazione di analisi può comunque assumere la forma di colonna precedente dopo che il database ha accettato quella nuova. Per ogni record rappresentativo, confrontare ciò che vede il cliente, ciò che riceve l'adempimento e ciò che preserva un'esportazione di controllo. Rilascia solo quando i consumatori concordano sulla stessa versione dell'indirizzo e mantieni un punto decisionale di rollback prima che le vecchie colonne o i payload non elaborati vengano rimossi. Documentare il confronto finale insieme al record del rilascio della migrazione.

• Confronta le stringhe Unicode e la struttura JSON
• Conteggio del troncamento, della codifica e delle conversioni null
• Leggere il livello dell'applicazione
• Mantieni uno strumento di riproduzione con indirizzi grezzi