วิธีสากลในการจัดเก็บที่อยู่ทางภูมิศาสตร์ / ที่ตั้งในฐานข้อมูลคืออะไร? [ปิด]


25

รูปแบบที่ถูกต้องของที่อยู่ทางภูมิศาสตร์ / ที่ตั้งซึ่งเหมาะสมกับที่อยู่ใด ๆ บนโลกคืออะไร ในขณะนี้ฉันมี:

  • ประเทศ
  • เมือง
  • ถนน
  • จำนวน
  • ข้อมูลตัวอักษร (เพื่อความง่าย)
  • ซิป
  • ลาดพร้าว / LNG

แต่ฉันเชื่อว่าฉันสามารถปรับปรุงได้: อาจมีรัฐ / ภูมิภาคของประเทศหรือบางอย่างเช่นพื้นที่ หรือไม่มีพื้นที่ / ภูมิภาค / รัฐในสิงคโปร์หรือฮ่องกง

อาจไม่มีถนน แต่มีถนนหรือถนนหรืออย่างอื่น จำนวนอาคารอาจเป็นแบบผสม อาจมีพื้น หมายเลขห้อง ฯลฯ ....


11
คุณต้องอธิบายว่าแอปพลิเคชันใดและใครเป็นผู้ให้ที่อยู่นั้น เช่นในร้านค้า / เว็บไซต์ส่วนใหญ่บนเว็บฉันไม่ได้พิมพ์ "ละติจูด / ลองจิจูด" ใด ๆ ซึ่งตรงกันข้ามกับสิ่งสำคัญสำหรับ ICBMs (หรือ GPS) นอกจากนี้ระดับความสูง (และเวลาและวันที่) มีความสำคัญในบางกรณี (คิดว่ามีเรือในทะเลหรือนักเดินทางในเอเวอเรสต์) ดังนั้นฉันไม่แน่ใจว่าจะมีคำตอบสากล
Basile Starynkevitch


6
@BasileStarynkevitch: ฉันคิดว่ามันไม่สำคัญมาก "สำหรับแอปพลิเคชันใด" แต่ "สำหรับกรณีการใช้งานอะไร" ตัวอย่างเช่นหากกรณีการใช้งานเพื่อให้แน่ใจว่าบริการไปรษณีย์ทั่วโลกสามารถส่งอีเมลได้ฉันคิดว่าคำถามนี้สามารถตอบได้อย่างสมเหตุสมผล อย่างไรก็ตามสำหรับกรณีการใช้งานนี้ไม่จำเป็นต้องใช้ "lat / lng"
Doc Brown

34
ฉันคิดว่ารูปแบบสากลสำหรับที่อยู่เป็นสตริงเดียว
Erik Eidt

12
ปัญหาที่คุณยกมานั้นช่างเจ็บปวดเหลือเกินที่มี บริษัท บางแห่งพัฒนาวิธีการที่เป็นสากลในการแก้ไขปัญหานี้เช่นwhat3words.com ( ย่อมาจากการแม็ปพิกัดตำแหน่งเป็นสามคำ) พวกเขาอ้างว่า "ด้วย what3words ทุกคนและทุกที่ในขณะนี้มีที่อยู่"
Roman Susi

คำตอบ:


51

Google ได้พัฒนาห้องสมุดที่ช่วยตรวจสอบที่อยู่ทางไปรษณีย์สำหรับทุกประเทศในโลกซึ่งคุณสามารถใช้ในการออกแบบสคีมาเพื่อเก็บข้อมูลนี้

มองหาช่องที่ต้องใช้บ่อยที่สุดข้ามที่อยู่จากฐานลูกค้าเป้าหมายเพื่อเริ่มต้นใช้งานและเมื่อคุณระบุประเทศอื่น ๆ ด้วยข้อกำหนดที่แตกต่างกันคุณสามารถปรับเปลี่ยนสคีมาของคุณได้


5
+1 สำหรับการศึกษาวิธีแก้ปัญหาที่มีอยู่ Addressระดับจาก Android SDK อาจจะเป็นอีกหนึ่งสถานที่ที่ดีที่จะเริ่มต้น
Kevin Krumwiede

4
การสแกนอย่างรวดเร็วของห้องสมุด Google แสดงให้เห็นว่ามันสร้างบนoasis-open.org/committees/ciq/download.shtml
grahamj42

@ grahamj42, lol หน้านั้นเสีย
Nakilon

41

วิธีสากลในการจัดเก็บที่อยู่ทางภูมิศาสตร์ / ที่ตั้งในฐานข้อมูลคืออันนี้

[Address] nvarchar(max) not null

สิ่งนี้ต้องการรหัสการเขียนโปรแกรมจำนวนน้อยที่สุด (และลดค่าใช้จ่ายในการบำรุงรักษา) และเข้ากันได้กับที่อยู่ใด ๆ อย่างไรก็ตามมีสามประเด็นใหญ่:

  • การขาดการตรวจสอบข้อมูลหมายความว่าเขตข้อมูลสามารถนำไปใช้เพื่อวัตถุประสงค์อื่นนอกเหนือจากการจัดเก็บที่อยู่ หนึ่งในวัตถุประสงค์คือการโจมตีแบบ DOS ที่มีจุดประสงค์เพื่อเติมช่องว่างของฐานข้อมูลของคุณโดยป้อนข้อมูล 2 GB ลงในช่องที่อยู่

  • ข้อมูลที่จัดเก็บด้วยวิธีนี้ทำให้เป็นไปไม่ได้ที่จะดำเนินการเพื่อวัตถุประสงค์ทางธุรกิจและการขุดข้อมูล ตัวอย่างเช่นมีผู้ใช้กี่คนจากอินเดีย ไม่มีวิธีที่จะบอกได้ง่ายเนื่องจากที่อยู่เหล่านั้นจะไม่ถูกทำให้เป็นมาตรฐาน

  • ผู้ใช้อาจป้อนที่อยู่ที่ไม่สมบูรณ์หรือผิดโดยไม่ได้ตั้งใจ

ในการลดปัญหาแรกให้ จำกัด เขตข้อมูลเป็นสิ่งที่คุณคิดว่าเป็นขีด จำกัด ที่สมเหตุสมผล โดยส่วนตัวแล้วฉันจะเริ่มต้นด้วย 1,000 ตัวอักษรและลดตามความยาวของที่อยู่ที่ป้อนโดยผู้ใช้คนแรกเมื่อคุณได้รับชุดข้อมูลที่มีขนาดใหญ่พอ

เพื่อลดปัญหาอีกสองประการคุณสามารถใช้ API ของบุคคลที่สามซึ่งแยกวิเคราะห์ที่อยู่และแสดงข้อมูลที่มีประเทศเมืองรหัสไปรษณีย์ ฯลฯ หากเป็นไปได้ API ควรแสดงที่อยู่บน แผนที่กลับไปยังผู้ใช้เพื่อลดความเสี่ยงสำหรับผู้ใช้ในการป้อนที่อยู่ไม่สมบูรณ์หรือไม่ถูกต้อง: ผู้ใช้ส่วนใหญ่รู้ว่าพวกเขาอยู่ที่ไหนและการเห็นตำแหน่งที่แตกต่างบนแผนที่จะให้เบาะแสว่าพวกเขาควรตรวจสอบอินพุตของพวกเขาทันที

โปรดทราบว่าสิ่งที่คุณใช้ API มันจะไม่สมบูรณ์แบบ มันจะค้นหาที่อยู่ส่วนใหญ่ แต่ไม่ใช่ทั้งหมด ซึ่งหมายความว่าหาก API บอกว่าไม่มีที่อยู่ แต่ผู้ใช้ยืนยันว่าเป็นเช่นนั้นคุณควรให้ความสำคัญกับผู้ใช้ก่อนแม้ว่าเขาอาจจะผิดก็ตาม

นอกจากนี้ยังหมายความว่าคุณยังควรเก็บอินพุตของผู้ใช้ดั้งเดิมพร้อมกับผลลัพธ์ของ API ซึ่งหมายความว่าสคีมากลายเป็น:

[RawAddress] nvarchar(max) not null
[ParsedAddress] xml null

หมายเหตุ: อย่างน้อยที่สุดคุณสามารถจัดเก็บประเทศแยกต่างหากหากจำเป็น ตัวอย่างเช่นมันอาจถูกอนุมานจากฟิลด์ที่อยู่โดยอัตโนมัติพร้อมตัวเลือกสำหรับผู้ใช้ที่จะเปลี่ยน
Matthieu M.

'ใช้ API' หมายถึงบางคนมีรูปแบบเป็นทางการของทุกประเทศ ไม่มีเหตุผลที่คุณไม่สามารถทำมันได้ด้วยตัวเอง
Ewan

@Ewan ไม่มีเหตุผลยกเว้นเวลาเงินภาษาและอุปสรรคอื่น ๆ
แอนดรูพูดว่า Reinstate Monica

แน่นอน แต่เราจะให้คำตอบเกี่ยวกับวิธีการทำสิ่งต่างๆหรือเปรียบเทียบราคาของคนอื่นที่ทำสิ่งต่าง ๆ ให้คุณหรือไม่
Ewan

@Ewan: คำถามเกี่ยวกับรูปแบบการจัดเก็บที่อยู่ API ไม่ได้กำหนดรูปแบบนี้: เป้าหมายของคำตอบของฉันคือแสดงว่าทันทีที่คุณมีฟิลด์ข้อความธรรมดาและ XML / JSON / ฟิลด์ใด ๆ สำหรับข้อมูลที่แยกวิเคราะห์คุณสามารถจัดเก็บและประมวลผลที่อยู่ทางสถิติจากที่ใดก็ได้ ในโลก.
Arseni Mourzenko

37

ไม่มีเลย

ทุกประเทศมีรูปแบบที่อยู่ที่แตกต่างกัน หากคุณโชคดีและพวกเขามีรูปแบบเลย!

เห็นได้ชัดว่าละติจูด / ลองจิจูดนั้นจะทำให้คุณได้จุดบนโลก แต่มันไม่ได้มีประโยชน์มากสำหรับการระบุบ้านเดี่ยว ลองพิจารณาการบล็อกแบบหอคอย

ทางออกที่ดีที่สุดของคุณคือการตรวจสอบรูปแบบเป็นทางการของแต่ละประเทศ นี่เป็นสิ่งที่ดีสำหรับฐานข้อมูลแบ็กเอนด์ของคุณ แต่คุณอาจจะต้องทำให้มันง่ายขึ้นสำหรับผู้ใช้เนื่องจากมันจะมีฟิลด์จำนวนมากมากกว่าที่คนส่วนใหญ่คุ้นเคย

ตัวอย่างเช่นในสหราชอาณาจักรมีสิ่งต่าง ๆ เช่น 'สถานที่สองแห่งที่พึ่งพา' แต่ไม่มีใครรู้ว่าคุณหมายถึงอะไร


3
เป็นวิธีสากลอะไร...........
Xwaro

40
@Xwaro พวกเขาเพียงแค่พูดว่าไม่มีใคร
Zymus

6
ฉันเดาว่า Xwaro หมายความว่าฉันกำลังสมมติที่อยู่บนโลก
Ewan

3
นี่คือแหล่งที่มาอย่างเป็นทางการสำหรับรูปแบบที่อยู่พิมพ์: สหภาพสากลไปรษณีย์
grahamj42

3
น่าสนใจ ฉันคิดว่านี่เป็นหน้าที่เกี่ยวข้องแม้ว่า: upu.int/en/activities/addressing/s42-standard/ ......คุณสามารถดูได้ว่า A: มีเพียงไม่กี่ประเทศเท่านั้นและ B: การแมปจาก s42 ไปยังรูปแบบที่อยู่ประเทศไม่ใช่ 1 ถึง 1
Ewan

21

รูปแบบสากลเท่านั้นที่จะมีฟิลด์ข้อความเดียวซึ่งอาจมีข้อความหลายบรรทัด สิ่งนี้จะช่วยให้ที่อยู่ที่เป็นไปได้ใด ๆ ในโลก


2
เยี่ยมมากตอนนี้ทุกคนสามารถอธิบายที่อยู่เดียวกันด้วยวิธีที่แตกต่างและเข้ากันไม่ได้ ฉันคิดว่าคำถามไม่ได้ถามเกี่ยวกับมาตรฐานดังนั้นนี่เป็นคำตอบทางเทคนิคที่ถูกต้อง
ไมเคิล

@Michael: ที่อยู่นั้นแตกต่างกันและเข้ากันไม่ได้ทั่วโลก มีคือไม่มีแม่แบบมาตรฐาน การมีฟิลด์หลายบรรทัดให้ผู้ใช้เขียนที่อยู่ที่ถูกต้องได้จริง
JacquesB

@Michael ฟิลด์ที่แยกจากกันมักจะบังคับให้ฉันตัดทอน / ย่อเขตข้อมูลหนึ่งหรืออื่น ๆ ซึ่งจะนำไปสู่การเป็นตัวแทนที่ไม่สอดคล้องกัน (โดยปกติยังใช้งานได้บริการไปรษณีย์ค่อนข้างมีประสบการณ์ในเรื่องนี้)
Hulk

ได้รับการยืนยัน: en.wikipedia.org/wiki/Address_(geography)
Eric.Void

เพียงชิ้นอาหารอันโอชะที่น่าสนใจนี้ไม่เป็นความจริงทางเทคนิค ในบางพื้นที่ของประเทศบางส่วนของที่อยู่จะถูกวาดเป็นรูปภาพ
KayakinKoder

9

ฉันได้พัฒนาโซลูชันซอฟต์แวร์เพื่อใช้ในหลายประเทศ เราแก้ไขปัญหานี้โดยเริ่มต้นด้วยเอนทิตีที่ใหญ่กว่าก่อนเช่นประเทศนั้นจะมีฟิลด์น้อยที่สุดหรือน้อยที่สุด มันใช้งานได้ดีสำหรับทุกประเทศที่เราทดลองมา นอกจากนี้เรายังมีระบบป้องกันซ้ำซ้อนที่ชาญฉลาดและการควบรวมสำหรับผู้ที่ได้รับในระบบเนื่องจากผู้ใช้มีความคิดสร้างสรรค์มาก ในส่วนผู้ดูแลเรามีคำสั่งฟิลด์ที่อยู่ต่อการตั้งค่าประเทศ เช่นญี่ปุ่นมีรหัสไปรษณีย์ / ไปรษณีย์ครั้งแรกที่เป็นสหราชอาณาจักร / สหรัฐอเมริกาล่าสุด

โดยทั่วไปเราใช้:

  • ประเทศ
  • โพสต์ / รหัสไปรษณีย์
  • รัฐ / จังหวัด / จังหวัด / ประเทศ
  • เมือง / จังหวัด / วิลเลจ
  • ถนน / ถนน / บล็อก
  • ชื่ออาคาร / จำนวน
  • ข้อมูลเฉพาะ / กำหนดเอง

เมื่อป้อนและบันทึกแล้วจะสามารถแสดงเวอร์ชันที่เชื่อมโยงกันโดยไม่จำเป็น

ดังที่ฉันได้กล่าวไปแล้วสิ่งนี้ได้ผลกับทุกประเทศที่เรามีซอฟต์แวร์ที่มีซอฟต์แวร์อยู่และเป็นผลมาจากการพัฒนามาตั้งแต่ปี 1989

หวังว่านี่จะช่วยได้บ้างหรืออย่างน้อยก็ให้ข้อมูลเชิงลึกอื่น


คุณตั้งชื่อคอลัมน์ใน db ของคุณอย่างไรสำหรับ "รัฐ / จังหวัด / จังหวัด / เขต"
Xwaro

6
@Xwaro ไม่สำคัญว่าชื่ออะไรก็ตามที่คุณรู้สึกว่านักพัฒนาของคุณจะสับสนน้อยที่สุด นี่เป็นเพราะชื่อเป็นซอฟต์แวร์ภายในของคุณและผู้ใช้จะไม่เห็น ที่อยู่จะไม่แสดงพร้อมชื่อของเขตข้อมูล No 10 Street Downing Street, City Westminster, State London, Country UKนั่นคือคุณไม่เคยเห็น แต่คุณจะเห็น10 Downing Street, Westminster, London, UK
slebetman

@slebetman คำถามคือ: คุณจะตั้งชื่อคอลัมน์อย่างไรในฐานข้อมูลของคุณสำหรับ "รัฐ / จังหวัด / จังหวัด / เขต" ไม่ใช่ "คุณจะแนะนำฉันให้ตั้งชื่อคอลัมน์อย่างไรในฐานข้อมูลของฉันสำหรับ" รัฐ / จังหวัด / จังหวัด / จังหวัด "?
Dari

@Dari มันไม่สำคัญหรอกฉันตั้งชื่อมันไม่ว่าฉันจะรู้สึกอย่างไรกับนักพัฒนาของฉันก็จะสับสนน้อยที่สุด นี่เป็นเพราะชื่อเป็นซอฟต์แวร์ภายในของฉันและผู้ใช้จะไม่เห็น ดังนั้นมันขึ้นอยู่กับสิ่งที่ทีมของฉันคุ้นเคย
slebetman

@slebetman - คุณชื่ออะไร
Dari

0

ตามที่ระบุไว้แล้วยูนิเวอร์แซลส่วนใหญ่ (แต่ไม่สามารถพิสูจน์ได้และมีประโยชน์น้อยที่สุด) เป็นฟิลด์ยูนิโคดขนาดใหญ่เพียงฟิลด์เดียว

คุณสามารถแยกประเทศออกจากที่อยู่ที่เหลือและจัดเก็บเป็นรหัสประเทศ ISO มันจะทำให้มาตรฐานของประเทศเป็นปกติและนำเสนอยูทิลิตี้บางอย่างในการตรวจสอบส่วนที่เหลือของที่อยู่

คุณสามารถแยกรหัสไปรษณีย์ aka รหัสไปรษณีย์จากที่อยู่ที่เหลือ สิ่งนี้จะมียูทิลิตี้บางอย่างในการตรวจสอบส่วนที่เหลือของที่อยู่และอาจเป็นประโยชน์ในการระบุตำแหน่งทางภูมิศาสตร์ ตัวอย่างเช่น: ในแคนาดาคุณสามารถระบุที่อยู่ใด ๆ ที่ไม่ซ้ำกันซึ่งระบุเฉพาะรหัสไปรษณีย์และหมายเลขถนน (เลขที่บ้านหรือที่รู้จัก) สิ่งนี้อาจไม่เป็นจริงในทุกประเทศ

การอุทิศเขตข้อมูลให้กับรัฐ / จังหวัดหรือเมืองเริ่มมีปัญหามากขึ้นเนื่องจากความแตกต่างของวิธีการที่แต่ละประเทศกำหนดที่อยู่ ฉันได้ตั้งค่าตารางที่อยู่ซึ่งมีสาขาดังกล่าวเนื่องจากผู้ชมเริ่มต้นมุ่งเน้นไปที่อเมริกาเหนือเพราะรู้ว่าผู้ชมจากต่างประเทศจะก่อปัญหาได้ในกรณีส่วนใหญ่พวกเขาสามารถเป็น "รองเท้าที่มีเขา" ใน แต่มันเป็น การประนีประนอมที่น่าอึดอัดใจและอาจล้มเหลว - แน่นอนไม่ใช่สากล


0

ตรงกันข้ามกับคำตอบของ Mitchdav ฉันจะแนะนำไม่ให้ใช้ห้องสมุดของ Google ฉันค้นหาที่เก็บข้อมูลสำหรับสถานที่นานาชาติหลายแห่งด้วยรูปแบบการกำหนดที่อยู่นอกรีตที่หวังว่าจะพบข้อมูลทดสอบหน่วย

ฉันคิดว่าทางออกที่ดีที่สุดของคุณคือการรักษาที่อยู่เป็นข้อความหลายบรรทัดแบบฟรี มันแย่มากที่คุณอาจไม่สามารถตรวจสอบที่อยู่ทั้งหมดได้ แต่รูปแบบการกำหนดที่อยู่บางอย่างแปลกและไม่คาดคิดและท้ายที่สุดความรับผิดชอบในการกรอกที่อยู่ที่ถูกต้องจะขึ้นอยู่กับผู้ใช้และในแอปพลิเคชันส่วนใหญ่ ที่อยู่ที่ไม่ถูกต้อง.

คุณอาจใช้ตัวตรวจสอบความถูกต้องเพื่อส่งคำเตือนแต่ไม่มีอะไรมากไปกว่านั้น แต่อย่าปฏิเสธที่อยู่ที่ไม่ผ่านการตรวจสอบเพราะคุณอาจสูญเสียลูกค้าบางราย ซึ่งนำไปสู่คำถามเกี่ยวกับวิธีสื่อสารคำเตือนไปยังผู้ใช้ในลักษณะที่จะสื่อสารว่าหากผู้ใช้อยู่ในพื้นที่ที่มีรูปแบบที่อยู่แปลก ๆ มันปลอดภัยที่จะเพิกเฉยต่อคำเตือน ...


-1

ในขณะที่คุณพูดที่อยู่บนโลกใบนี้มีความยาวน้อยหรือ ...

https://what3words.com

คำ 3 คำคืออัลกอริธึม (ไม่ใช่ฐานข้อมูลดังนั้นสามารถฝังลงในสิ่งใดก็ได้) ที่สามารถกำหนดแพทช์ 3x3 เมตรได้ทุกที่บนโลก

ตองกาและรัฐอื่น ๆ สองสามแห่งได้นำมาใช้เป็นระบบรหัสไปรษณีย์ในขณะที่มันจะไม่แทนที่มันเป็นภาพซ้อนทับที่ดูเท่ห์และสร้างขึ้นมาอย่างดี

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.