แนวทางปฏิบัติที่ดีที่สุดในการจัดเก็บที่อยู่ไปรษณีย์ในฐานข้อมูล (RDBMS)?

มีการอ้างอิงที่ดีสำหรับแนวทางปฏิบัติที่ดีที่สุดในการจัดเก็บที่อยู่ทางไปรษณีย์ใน RDBMS หรือไม่ ดูเหมือนว่าจะมีข้อแลกเปลี่ยนมากมายที่สามารถทำได้และข้อดีข้อเสียมากมายสำหรับแต่ละข้อที่ต้องประเมิน - นี่เป็นสิ่งที่ต้องทำครั้งแล้วครั้งเล่า? อาจมีคนเขียนบทเรียนบางอย่างที่ได้เรียนรู้จากที่ไหนสักแห่ง?

ตัวอย่างของการแลกเปลี่ยนที่ฉันกำลังพูดถึงคือการจัดเก็บรหัสไปรษณีย์เป็นจำนวนเต็มเทียบกับช่องถ่านควรจัดเก็บหมายเลขบ้านเป็นช่องแยกหรือเป็นส่วนหนึ่งของที่อยู่บรรทัดที่ 1 ควรทำให้หมายเลขชุด / อพาร์ทเมนต์ / ฯลฯ เป็นมาตรฐานหรือเก็บไว้เป็น กลุ่มข้อความในที่อยู่บรรทัดที่ 2 คุณจัดการ zip +4 อย่างไร (แยกช่องหรือช่องใหญ่ช่องเดียวจำนวนเต็มเทียบกับข้อความ) เป็นต้น

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

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

นี่คือส่วนสำคัญของสคีมาซึ่งคัดลอกมาจากหน้าโมดูล:

country => Country (always required, 2 character ISO code)
name_line => Full name (default name entry)
first_name => First name
last_name => Last name
organisation_name => Company
administrative_area => State / Province / Region (ISO code when available)
sub_administrative_area => County / District (unused)
locality => City / Town
dependent_locality => Dependent locality (unused)
postal_code => Postal code / ZIP Code
thoroughfare => Street address
premise => Apartment, Suite, Box number, etc.
sub_premise => Sub premise (unused)

บทเรียนที่ฉันได้เรียนรู้:

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

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

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

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

หากคุณต้องการข้อมูลที่ครอบคลุมเกี่ยวกับวิธีที่ประเทศอื่น ๆ ใช้ที่อยู่ทางไปรษณีย์นี่คือลิงค์อ้างอิงที่ดีมาก (Columbia University):

คำแนะนำเชิงบังคับของ Frank สำหรับที่อยู่ไปรษณีย์ที่อยู่ที่
มีประสิทธิภาพสำหรับไปรษณีย์ระหว่างประเทศ

คุณควรพิจารณาการจัดเก็บเลขที่บ้านเป็นช่องอักขระมากกว่าตัวเลขเนื่องจากกรณีพิเศษเช่น "ตัวเลขครึ่งตัว" หรือที่อยู่ปัจจุบันของฉันซึ่งเป็น "129A" ​​- แต่ A ไม่ถือเป็นอพาร์ตเมนต์ เลขที่สำหรับบริการจัดส่ง.

ฉันได้ทำสิ่งนี้แล้ว (จำลองโครงสร้างที่อยู่อย่างเข้มงวดในฐานข้อมูล) และฉันจะไม่ทำอีก คุณไม่สามารถจินตนาการได้ว่ามีข้อยกเว้นที่บ้าคลั่งเพียงใดที่คุณต้องคำนึงถึงเป็นกฎ

ฉันจำปัญหาเกี่ยวกับรหัสไปรษณีย์ของนอร์เวย์ได้อย่างคลุมเครือ (ฉันคิดว่า) ซึ่งมีทั้งหมด 4 ตำแหน่งยกเว้นออสโลซึ่งมี 18 ตำแหน่งหรือมากกว่านั้น

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

(เราลงทะเบียนบุคคลเหล่านั้นด้วยที่อยู่ต่างประเทศในประเทศด้วยรหัส ISO 'ZZ')

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

มีคำตอบที่มีอยู่แล้วจำนวนมากอย่างแน่นอน (ดูตัวอย่างแบบจำลองข้อมูลที่DatabaseAnswersเป็นต้น) คำตอบที่มีอยู่แล้วจำนวนมากมีข้อบกพร่องภายใต้สถานการณ์บางอย่าง (ไม่ได้เลือกคำตอบของ DB เลย)

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

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

ถ้าคุณไม่คิดเลขบนถนนหรือรหัสไปรษณีย์คุณก็แค่ชวนให้เจ็บปวดในอนาคตโดยเก็บไว้เป็นตัวเลข

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

ต้นทุนของพื้นที่ดิสก์จะถูกกว่าค่าใช้จ่ายในการแก้ไขในภายหลังมาก ... y2k มีใครบ้าง?

เพิ่มสิ่งที่ @ Jonathan Lefflerและ @ Paul Fisherได้กล่าวไว้

หากคุณเคยคาดหวังว่าจะมีที่อยู่ไปรษณีย์สำหรับแคนาดาหรือเม็กซิโกเพิ่มในข้อกำหนดของคุณการจัดเก็บpostal-codeเป็นสตริงเป็นสิ่งที่จำเป็น แคนาดามีรหัสไปรษณีย์ที่เป็นตัวเลขและตัวอักษรและฉันจำไม่ได้ว่าเม็กซิโกหน้าตาเป็นอย่างไร

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

*********************************
  Field              Type
*********************************
  address_id (PK)    int
  unit               string
  building           string        
  street             string
  city               string
  region             string
  country            string
  address_code       string
*********************************

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

หากผลรวมของซิปไม่มีความหมายเลย Zips as number ก็ไม่มีประโยชน์

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

คุณสามารถจัดการที่อยู่เฉพาะประเทศได้โดยใช้ตารางสองตาราง: ตารางทั่วไปหนึ่งตารางที่มี 10 คอลัมน์ VARCHAR2 คอลัมน์ตัวเลข 10 คอลัมน์ตารางอื่นที่แมปฟิลด์เหล่านี้เพื่อแจ้งและมีคอลัมน์ประเทศที่ผูกโครงสร้างที่อยู่กับประเทศ

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

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

แรงบันดาลใจจากคำตอบฐานข้อมูล

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

ฉันจะใส่ฟิลด์ทั้งหมดเข้าด้วยกันในฟิลด์ NVARCHAR (1000) ขนาดใหญ่โดยมีองค์ประกอบ textarea เพื่อให้ผู้ใช้ป้อนค่าสำหรับ (เว้นแต่คุณต้องการทำการวิเคราะห์เช่นรหัสไปรษณีย์) อินพุตบรรทัดที่อยู่ 1 บรรทัดที่อยู่ 2 และอื่น ๆ ทั้งหมดนั้นน่ารำคาญมากหากคุณมีที่อยู่ที่ไม่เหมาะสมกับรูปแบบนั้น (และคุณรู้ไหมว่ามีประเทศอื่นที่ไม่ใช่สหรัฐอเมริกา)