Tenemos un equipo que diseña las tablas y las relaciones para los desarrolladores de software. En nuestra organización, son bastante estrictos sobre la aplicación de la normalización de 3NF, lo que para ser honesto, estoy de acuerdo con el tamaño de nuestra organización y cómo cambian las necesidades o los clientes con el tiempo. Solo hay un área que no tengo claro sobre las razones detrás de su decisión de diseño: direcciones.
Si bien esto se centra principalmente en las direcciones en los Estados Unidos, creo que esto podría aplicarse a cualquier país que lo haga. Cada parte de una dirección obtiene su propia columna en la tabla de direcciones. Por ejemplo, tome esta dirección estadounidense retorcida:
Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222
Se dividiría en la base de datos de esta manera:
- Callejero: 485
- Fracción callejera: 1/2
- Calle pre-direccional: N (Norte)
- Nombre de la calle: Smith
- Tipo de calle: ST (calle)
- Calle post-direccional: SW (suroeste)
- Ciudad: Chicago
- Estado: IL (Illinois)
- Código postal: 11111
- Código ZIP4: 2222
- País (se supone que es EE. UU.)
- Atención: Jane Doe
- PO Box: NULL
- Tipo de vivienda: APT (Apartamento)
- Número de vivienda: 300B
Y habría algunas otras columnas relacionadas con rutas rurales y rutas de contrato. Además, nuestra aplicación específica probablemente tendrá algunas direcciones internacionales. Los modeladores de datos dijeron que agregarían columnas específicas para direcciones internacionales, que serían los campos normales de línea 1, línea 2.
Al principio pensé que esto era una MANERA al agua. Investigar en línea repetidamente se refiere al uso de la línea de dirección 1, 2, 3 y posiblemente 4, luego dividir la ciudad, la región y el código postal. Tenemos un caso de uso para nuestra nueva aplicación donde esta granularidad es beneficiosa. Tenemos que validar que el usuario no está creando un negocio duplicado, y verificar la dirección es una de las validaciones. Nos podemos conseguir que funcione con línea de dirección 1 y 2, pero sería más difícil.
En cuanto a nuestra aplicación específica, necesitamos almacenar múltiples tipos de direcciones para empresas y personas (física, postal, envío, etc.). Es posible que necesitemos generar cartas de formulario imprimibles, pero ese requisito no se ha discutido hasta ahora.
Algunas otras cosas que las aplicaciones de nuestra organización deben admitir:
- Auditoría (con tablas de historial completas)
- Impresión de etiquetas postales
- Generando formularios impresos
- Informes (para gobiernos nacionales y regionales)
Si bien es posible que nuestra aplicación no esté haciendo todo lo que hacen todas las demás aplicaciones, la división de direcciones en múltiples componentes es un estándar empresarial donde trabajo. Independientemente de si nuestra aplicación se beneficiaría de ello, nos vemos obligados a hacerlo.
Pregunta de StackOverflow semi relacionada: ¿Dónde está un buen analizador de direcciones que se cerró, pero ilustra cuán difícil puede ser el análisis de direcciones?
Para que yo pueda entender mejor su decisión de diseño y vender a nuestro cliente la idea ...
¿Qué problemas se resuelven dividiendo la dirección de la calle en columnas individuales?
Puntos de bonificación para cualquiera que haya implementado un sistema como este, porque se encontraron con problemas.