una sirve que practicar para ejemplo descargar datos crear como codigo mysql street-address

mysql - sirve - sql download



Mejores prácticas/estándares para almacenar una dirección en una base de datos SQL (6)

En primer lugar, como una persona que pasa la mayor parte del día profesional trabajando con direcciones, es difícil gestionarlas desde una perspectiva de datos.

Si le preguntas a 5 personas en qué dirección viven; Encontrarás que obtienes 5 respuestas diferentes. Si bien usted y yo podemos decir que 123 Main Street Apt 1 y Apt 1 123 Main Street son la misma dirección, el programa de base de datos tendrá un desafío.

Si utiliza direcciones centradas en Estados Unidos, el software certificado por CASS de casi cualquier proveedor estandarizará sus direcciones razonablemente bien. Yo recomendaría un formato simple como sigue:

  • Dirección 1
  • Dirección 2
  • Dirección 3
  • Ciudad
  • Estado
  • Cremallera
  • Zip + 4 (Llevaría esto para que las búsquedas sean más fáciles cuando se comprueban duplicados)

Sin embargo, si desea una dirección universal, vería el estándar ADIS de IdeaAlliance. Este estándar se puede utilizar para desglosar (analizar) las direcciones de casi cualquier país en las partes relevantes. Luego se pueden volver a armar utilizando plantillas / componentes basados ​​en los estándares de la Unión Postal Universal (Estándar UPU S42 sobre Componentes y Plantillas de Direcciones Postales Internacionales).

La gran ventaja de este formato es que las direcciones que no existen en una base de datos postal como CASS se pueden ingresar y almacenar como partes separadas.

Me pregunto si hay algún tipo de "estándar" para almacenar direcciones de EE. UU. En una base de datos. Parece que esta es una tarea común, y debería haber algún tipo de estándar.

Lo que estoy buscando es un esquema específico de cómo las tablas de la base de datos deberían funcionar e interactuar, ya en la tercera forma normal, incluidos los tipos de datos (MySQL). Un buen documento UML funcionaría.

Tal vez solo estoy siendo perezoso, pero esta es una tarea muy común, y estoy seguro de que alguien ha publicado una manera eficiente de hacer esto en algún lugar. Simplemente no sé dónde mirar y Google no está ayudando. Por favor, apúntame al recurso. Gracias.

EDITAR

Aunque esta es una pregunta más general, me gustaría aclarar mis necesidades específicas.

Las direcciones se utilizarán para especificar las direcciones de las ubicaciones de los eventos. Estas direcciones deberán estar en un formato que se pueda analizar y buscar mejor, y que también sea utilizada por cualquier aplicación de terceros a la que pueda llegar a vincular mi fuente de datos.

ADEMÁS. Los datos serán geocodificados (largos, lat) en la entrada y se almacenarán por separado, por lo que debe ajustarse al protocolo (aún no decidido) de cualquier geocodificador / aplicación / biblioteca que haga eso.


He tenido que intentar hacer esto antes y encontré este documento que te da algunos consejos. Terminé archivando mi esquema ya que mi aplicación tiene que tratar con direcciones internacionales.


Miré en esto hace un tiempo, pero para direcciones internacionales. No encontré mucho en el camino de un consenso. Sin embargo, para los EE. UU., Encontré el Estándar de Datos de Dirección Postal, Referencia y Dirección Postal de Estados Unidos (borrador) :

http://www.fgdc.gov/standards/projects/FGDC-standards-projects/street-address/index_html

No creo que en realidad proporcionen ideas específicas de esquema de base de datos, pero podría ser un buen punto de partida.


Primero, el "mejor" medio para almacenar una dirección depende en gran medida de cómo se utilizará. ¿Es solo para referencia o búsqueda en la ciudad? ¿Planea abordar sobres? ¿Se integrará con un sistema de envío como FedEx o UPS? ¿Almacenarás direcciones no estadounidenses? Una vez que ingresa en el ámbito de la integración con algo que se envía, debe comenzar a buscar CASS . Esta es una especificación para el manejo de las direcciones de USPS. Hay aplicaciones que están certificadas por CASS que almacenarán y verificarán las direcciones. Por lo tanto, la segunda práctica recomendada sería tratar de evitar reinventar la rueda y ver si existe un sistema que solucione su problema, especialmente si va a ser internacional. Desea aprovechar el hecho de que otra persona ha elaborado todos los detalles sobre cómo almacenar las direcciones de manera adecuada y eficiente para muchos países de todo el mundo en lugar de tener que hacer esa investigación usted mismo.


questions Very similar have han hecho antes.

Las direcciones son confusas, en el mejor de los casos.

Depende en parte de lo que quieras hacer con las direcciones. Si va a utilizarlos para enviarlos por correo a otras personas, simplemente necesita grabar la imagen que aparecerá en la etiqueta de la dirección de forma conveniente. Si vas a analizar la dirección, tienes que trabajar mucho más.

Recuerde que la primera vez que tenga que tratar con alguien fuera de los EE. UU., Todas las reglas anteriores se desviarán. Puede ser estrictamente solo en los Estados Unidos, pero tenga cuidado.


http://www.upu.int tiene los estándares de formato para direcciones internacionales. La publicación 28 en http://usps.com tiene los estándares de formato de los Estados Unidos.

El USPS quiere que los siguientes componentes de direcciones no puntuados se concatenen en una sola línea:

* house number * predirectional (N, SE, etc) * street * suffix (AVE, BLVD, etc) * postdirectional (SW, E, etc) * unit (APT, STE, etc) * apartment/suite number

Por ejemplo, 102 N MAIN ST SE APT B.

Si mantiene la línea de dirección completa como un solo campo en su base de datos, la entrada y la edición son fáciles, pero las búsquedas pueden ser más difíciles (por ejemplo, en el caso de que el SURESTE ESTE sea la calle ESTE como en S EAST LN o que sea LANE as en SE LANE ST?).

Si mantiene la dirección analizada en campos separados, las búsquedas de componentes como el nombre de la calle o los apartamentos se vuelven más fáciles, pero tiene que adjuntar todo a la salida, necesita el software CASS para analizar correctamente, y los apartados de correos, direcciones de rutas rurales y APO / Las direcciones FPO tienen parsings especiales.

Una ubicación física con múltiples direcciones en esa ubicación es un edificio de varias unidades, en cuyo caso, las letras / números después de que unidades como APT y STE designan la dirección, o es una Agencia de Recepción de Correo Comercial (por ejemplo, una tienda UPS) y un buzón de correo privado / privado. el número se agrega (como 100 MAIN ST STE B PMB 102), o es un negocio con un punto de entrega de USPS y el correo se enruta después de la entrega de USPS (que generalmente requiere un campo de correo postal separado que la compañía puede necesitar pero el USPS no querrá) en la línea de dirección).

Un contacto con más de una dirección física suele ser un negocio o una persona con una dirección física y un apartado postal. Tenga en cuenta que es común que cada dirección tenga un código postal diferente.

Es bastante típico que una transacción comercial tenga una dirección de envío y una dirección de facturación (nuevamente, con diferentes códigos postales). La información que guardo para CADA dirección es:

* name prefix (DR, MS, etc) * first name and initial * last name * name suffix (III, PHD, etc) * mail stop * company name * address (one line only per Pub 28 for USA) * city * state/province * ZIP/postal code * country

Normalmente imprimo paradas de correo en algún lugar entre el nombre de la persona y la compañía porque el país contiene el estado / ZIP que contiene la ciudad que contiene la dirección que contiene la compañía que contiene la parada de correo que contiene la persona. Utilizo el software CASS para validar y estandarizar direcciones cuando se ingresan o se editan.