Diseño de bases de datos de direcciones internacionales: campos, valores sin procesar y control de versiones

Entrada separada, componentes analizados y salida renderizada

La entrada sin procesar es evidencia, los campos analizados respaldan la lógica de búsqueda y de negocios, y las líneas representadas siguen el orden de los países. Mantener solo uno evita auditorías posteriores y actualizaciones del analizador.

Almacene rawAddressLines, parsedComponents, normalizedAddress y el proveedor/versión de normalización. Un error de normalización no debería destruir el registro sin formato.

Los identificadores que parecen numéricos siguen siendo texto.

Los códigos postales y los números de inmueble pueden contener ceros a la izquierda, letras, espacios, guiones y rangos. Los tipos enteros pierden datos y fuerzan parches específicos de cada país.

Utilice texto Unicode en todas partes. Derive límites de longitud a partir de conjuntos de datos reales y límites comerciales, no de muestras promedio en inglés.

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

No mezcle cadenas vacías, nulas y faltantes

Defina si una segunda línea ausente se omite, es nula o está vacía, luego normalícela en el límite. De lo contrario, las consultas, la deduplicación y las exportaciones tratan un estado como tres.

Nunca complete las líneas faltantes con N/A o un guion; los marcadores de posición se filtran en las etiquetas.

Utilice instantáneas para pedidos y registros de auditoría

Una entrada de la libreta de direcciones puede cambiar, mientras que un pedido o factura debe conservar su dirección histórica. Hacer referencia solo a un addressId actual muta el historial.

Instantánea de líneas renderizadas, componentes, estado de verificación y marca de tiempo.

• Los pedidos no cambian con la libreta de direcciones.
• Registrar proveedor y versión del normalizador
• Estado de verificación de marca de tiempo
• No registre direcciones reales completas innecesariamente

Validar migraciones con fixtures de varios países

Fixtures de ida y vuelta que contienen inmuebles con nombre en el Reino Unido, código postal alfanumérico canadiense, Unicode en alemán, texto fuente en japonés y ceros a la izquierda. Compare campos semánticos y JSON sin procesar, no solo recuentos de filas.

Un ensayo de migración debe contar valores truncados, errores de decodificación y cambios de cadena vacía a nula. El éxito de la base de datos no es suficiente si la aplicación no puede reconstruir las líneas originales después de leerlas. Produzca una diferencia estructural entre registros antiguos y nuevos y prepare una ruta de reproducción a partir de los datos rawAddress retenidos para transformaciones irreversibles.

Ejecute este paquete con una base de datos de prueba limpia y una copia desinfectada de esquemas en forma de producción. Los índices realistas, las restricciones y los valores nulos heredados a menudo revelan un comportamiento que un esquema vacío ideal no puede reproducir.

Mida la ruta de lectura de la aplicación y el trabajo de migración. Un serializador ORM, un índice de búsqueda, un caché o una exportación de análisis aún pueden asumir la forma de columna anterior después de que la base de datos acepte la nueva. Para cada registro representativo, compare lo que ve el cliente, lo que recibe y lo que preserva una exportación de auditoría. Libere solo cuando esos consumidores estén de acuerdo con la misma versión de dirección y mantenga un punto de decisión de reversión antes de que se eliminen las columnas antiguas o las cargas útiles sin procesar. Documente la comparación final junto con el registro de liberación de migración.

• Compare las cadenas Unicode y la estructura JSON
• Contar truncamiento, codificación y conversiones nulas
• Leer la capa de aplicación
• Mantenga una herramienta de reproducción de direcciones sin formato