Datenbankdesign, Google Maps und Adressfelder

Question

Ich möchte die Adressen meiner Nutzer sammeln, damit ich sie auf einer Google-Karte darstellen kann. Ich weiß, dass ich die Längen- und Breitenwerte ihrer Adresse speichern muss, die ich von der Google Map API erhalten kann.

Ich bin auf der Suche nach Empfehlungen, wie ich die verschiedenen Adressbestandteile aufteilen und in der Datenbank speichern kann. Ich sehe häufig Dinge wie diese:

• Anschrift Zeile 1
• Adresse Zeile 2
• Stadt
• Staat/Region/Provinz
• ZIP/Postleitzahl
• Land

Google schlüsselt diese Adressbestandteile jedoch anders auf. Siehe zum Beispiel: http://maps.googleapis.com/maps/api/geocode/json?address=1600+Amphitheater+Parkway,+Mountain+View,+CA&sensor=false

Ich bin mir nicht sicher, welche Teile der Google-Adresskomponenten dem entsprechen, was man üblicherweise in Webformularen sieht (z. B. ist administrative_area_level_1 immer das Bundesland/die Region/die Provinz?). Ich möchte die verschiedenen Adressbestandteile so atomar wie möglich speichern, damit ich später bei der Anzeige der Adressinformationen die größtmögliche Kontrolle habe.

HINWEIS: Ich plane auch, die formatted_address da ich denke, dass dies in einigen Fällen nützlich sein könnte.

Was sollte ich also in meiner Datenbank speichern?

Answer 1

Dieser Abschnitt der Geokodierungsdokumentation bietet eine ziemlich gute Beschreibung der Datentypen, die Sie vom Reverse-Geocoder zurückerhalten. Diese Datentypen wurden von Google entwickelt, um jede Adresse auf der Welt zu beschreiben, und sind daher wahrscheinlich ein guter Ausgangspunkt.

Nach dem folgenden Zitat beschreibt administrative_area_level_1 subnationale Gerichtsbarkeiten, Bundesstaaten in den USA/Australien, Präfekturen in Japan, Provinzen in Frankreich usw:

administrative_area_level_1 bezeichnet eine zivile Einheit erster Ordnung unterhalb der Landesebene. Innerhalb der Vereinigten Staaten, diese administrativen Ebenen die Bundesstaaten. Nicht alle Nationen weisen diese Verwaltungsebenen auf.

Sie müssen wahrscheinlich vorsichtig sein mit den Annahmen, die Sie bezüglich dieser Datentypen für andere Länder treffen. Zum Beispiel ist die verwaltungsbereich_ebene_1 für Adressen in London ist England . Aber mit einem guten Verständnis dieses Schemas sollten Sie in der Lage sein, überall auf der Welt ortsabhängige Adressen darzustellen.