Posta adreslerini bir veritabanında (RDBMS) depolamak için en iyi uygulamalar?

Bir RDBMS'de posta adreslerini depolamaya yönelik en iyi uygulamalar için iyi referanslar var mı? Görünüşe göre yapılabilecek pek çok değiş tokuş var ve her biri için değerlendirilecek birçok artı ve eksiler var - elbette bu defalarca yapıldı? Belki birisi en azından bir yerde öğrenilen bazı dersler yazmıştır?

Bahsettiğim değiş tokuşların örnekleri, posta kodunu bir tamsayı ile bir karakter alanı olarak depolamak, ev numarası ayrı bir alan veya adres satırı 1'in bir parçası olarak saklanmalı mı, daire / apartman / vb numaraları normalleştirilmeli mi yoksa sadece bir 2. adres satırındaki metin yığını, zip + 4'ü (ayrı alanlar veya bir büyük alan, tam sayıya karşı metin) nasıl kullanacaksınız? vb.

Bu noktada öncelikle ABD adresleriyle ilgileniyorum, ancak kendinizi küreselleşmenin olasılığına karşı hazırlamada bazı en iyi uygulamalar olduğunu düşünüyorum (örneğin alanları, posta kodu yerine eyalet veya posta kodu yerine bölge gibi uygun şekilde adlandırmak, vb.

Daha fazla uluslararası kullanım için, dikkate alınması gereken bir şema, Drupal Adres Alanı tarafından kullanılan şemadır . XNAL standardına dayanıyor ve çoğu uluslararası vakayı kapsıyor gibi görünüyor. Bu modülü biraz araştırmak, adresleri uluslararası olarak yorumlamak ve doğrulamak için bazı güzel incileri ortaya çıkaracaktır. Ayrıca ISO kodları ile güzel bir dizi idari bölgeye (il, eyalet, bölge vb.)

Modül sayfasından kopyalanan şemanın özü şu şekildedir:

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)

Öğrendiğim dersler:

• Hiçbir şeyi sayısal olarak saklamayın.
• Mümkünse ülke ve idari bölgeyi ISO kodları olarak saklayın.
• Bilmediğinizde, alan gerektirme konusunda gevşek olun. Bazı ülkeler, aldığınız alanları, locality& gibi temel şeyleri bile kullanmayabilir thoroughfare.

"Uluslararası" bir kullanıcı olarak, yalnızca ABD biçimindeki adreslere yönelik bir web sitesiyle uğraşmaktan daha sinir bozucu bir şey yoktur. İlk başta biraz kaba ama doğrulama da aşırı kıskanç olduğunda ciddi bir sorun haline geliyor.

Küreselleşmekle ilgileniyorsanız, verebileceğim tek tavsiye, işleri serbest biçimde tutmaktır. Farklı ülkelerin farklı kuralları vardır - bazılarında bina numarası sokak adından önce gelir, bazılarında sonra gelir. Bazılarının eyaletleri, bazı bölgeleri, bazı ilçeleri, bazılarının kombinasyonları var. Burada Birleşik Krallık'ta posta kodu bir posta kodu değildir, hem harf hem de rakam içeren bir posta kodudur.

Bir posta kodu için ayrı bir alanla birlikte ~ 10 satırlık değişken uzunluklu dizeleri öneririm (ve ulusal hassasiyetlerle başa çıkmak için bunu nasıl açıkladığınıza dikkat edin). Kullanıcı / müşterinin adreslerini nasıl yazacağına karar vermesine izin verin.

Diğer ülkelerin posta adreslerini nasıl kullandığı hakkında kapsamlı bilgiye ihtiyacınız varsa, işte çok iyi bir referans bağlantısı (Columbia Üniversitesi):

Frank'in Uluslararası Posta için Etkili Adresleme Posta Adreslerine Yönelik Zorunlu Kılavuzu

"Yarım sayı" gibi özel durumlar nedeniyle veya "129A" ​​gibi bir şey olan şu anki adresimden dolayı bina numarasını bir sayıdan ziyade bir karakter alanı olarak saklamayı kesinlikle düşünmelisiniz - ancak A bir apartman olarak kabul edilmez teslimat hizmetleri için numara.

Bunu yaptım (bir veritabanındaki adres yapılarını titizlikle modelledim) ve bir daha asla yapmam. Kural olarak dikkate almanız gereken istisnaların ne kadar çılgın olduğunu hayal bile edemezsiniz.

Norveç posta kodlarıyla ilgili bazı sorunları belirsiz bir şekilde hatırlıyorum (sanırım), bunlar 18 veya daha fazla olan Oslo dışında 4 pozisyonun tümü idi.

Tüm kendi ulusal adreslerimiz için coğrafi olarak doğru posta kodlarını kullanmaya başladığımız andan itibaren, epeyce insanın postalarının çok geç gelmesinden şikayet etmeye başladığından kesinlikle eminim. Bu insanların posta bölgeleri arasındaki bir sınırın yakınında yaşadıkları ortaya çıktı ve biri gerçekten posta bölgesinde, mesela 1600'de yaşamış olmasına rağmen, postasının 1610 numaralı posta alanına gönderilmesi gerekiyordu, çünkü gerçekte bu komşu posta alanıydı bu ona gerçekten hizmet etti, bu yüzden postasını doğru posta alanına göndermek, doğru posta ofisinde yanlış posta alanına iletmek için gereken istenmeyen müdahale nedeniyle, postayı birkaç gün daha uzun sürebilirdi ...

(Yurtdışında adresi olan kişileri ISO-kodu 'ZZ' ile kaydettirdik.)

Kesinlikle " İlişkisel bir veritabanındaki adres bilgisini modellemek için iyi bir yol mu " konusuna mutlaka danışmalısınız , ancak sorunuz bunun doğrudan bir kopyası değildir.

Elbette önceden var olan birçok cevap vardır (örneğin, DatabaseAnswers'daki örnek veri modellerine bakın). Önceden var olan cevapların çoğu bazı durumlarda kusurludur (DB Cevapları hiç seçilmemiştir).

Dikkate alınması gereken önemli bir konu, adreslerin kapsamıdır. Veritabanınızın uluslararası adreslerle ilgilenmesi gerekiyorsa, yalnızca bir ülkedeki adreslerle uğraşmak zorunda olduğunuzdan daha esnek olmalısınız.

Benim görüşüme göre, hem adresin "adres etiketi görüntüsünü" kaydetmek hem de içeriği ayrı ayrı analiz etmek çoğu zaman (bu her zaman anlamına gelmez ) mantıklıdır. Bu, örneğin farklı ülkeler arasında posta kodlarının yerleştirilmesi arasındaki farklılıklarla başa çıkmanıza olanak tanır. Elbette, farklı ülkelerin eksantrikliklerini ele alan bir analizör ve bir formatlayıcı yazabilirsiniz (örneğin, ABD adresleri 2 veya 3 satıra sahiptir; aksine, İngiliz adresleri önemli ölçüde daha fazla olabilir; periyodik olarak yazdığım bir adreste 9 satır vardır). Ancak analiz ve biçimlendirmeyi insanların yapmasını sağlamak ve DBMS'nin verileri depolamasına izin vermek daha kolay olabilir.

Sokak numaraları veya posta kodları üzerinde matematik yapmayacaksanız, onları sayısal olarak saklayarak gelecekteki acıları davet ediyorsunuz.

Burada ve orada birkaç bayt kaydedebilir ve belki daha hızlı bir dizin elde edebilirsiniz, ancak ABD postası veya uğraştığınız başka bir ülke kodlara alfaların eklenmesine karar verdiğinde ne yaparsınız?

Disk alanının maliyeti, daha sonra onu tamir etmenin maliyetinden çok daha ucuz olacak ... y2k kimse var mı?

Ne @ ekleme Jonathan Leffler ve @ Paul Fisher söylediler

Gereksinimlerinize Kanada veya Meksika için posta adreslerinin eklenmesini bekliyorsanız, postal-codebir dize olarak saklamak şarttır . Kanada'da alfasayısal posta kodları var ve Meksika'nın aklımda neye benzediğini hatırlamıyorum.

En küçük ayrık birimden en büyüğe tüm olası alanları listelemenin en kolay yol olduğunu buldum. Kullanıcılar uygun gördükleri alanları dolduracaklardır. Adres tablom şöyle görünüyor:

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

ZIP'i NUMBER veya VARCHAR olarak depolamanın "değiş tokuşu" nerede? Bu sadece bir seçim - her ikisinin de faydası olmadıkça ve diğerlerini elde etmek için bazı avantajlardan vazgeçmeniz gerekmedikçe, bu bir takas değildir.

Fermuarların toplamının bir anlamı olmadıkça, sayı olarak fermuarlar kullanışlı değildir.

Bu aşırı olabilir, ancak birden çok ülkede işe yarayacak bir çözüme ihtiyacınız varsa ve adresin bazı kısımlarını programlı olarak işlemeniz gerekiyorsa:

iki tablo kullanarak ülkeye özgü adres işlemeye sahip olabilirsiniz: 10 VARCHAR2 sütunu olan bir genel tablo, 10 Numara sütunu, bu alanları bilgi istemleriyle eşleyen ve bir ülkeye bir adres yapısı bağlayan bir ülke sütununa sahip başka bir tablo.

Bir adresi doğrulamanız veya kredi kartı ödemelerini işleme koymak için kullanmanız gerekirse, en azından küçük bir yapıya ihtiyacınız olacaktır. Serbest biçimli bir metin bloğu bunun için pek işe yaramaz.

Posta kodu, tüm adresi kullanmadan ödeme kartı işlemlerini doğrulamak için yaygın olarak kullanılan isteğe bağlı bir alandır. Öyleyse bunun için ayrı ve geniş bir alana sahip olun (en az 10 karakter).

Veritabanı Cevaplarından Esinlenilmiştir

Line1
Line2
Line3
City
Country_Province
PostalCode
CountryId
OtherDetails

Tüm alanları büyük bir NVARCHAR (1000) alanına, kullanıcının değerini girmesi için bir metin alanı öğesi ile bir araya getirirdim (örneğin, posta kodlarında analiz yapmak istemiyorsanız). Bu formata uymayan bir adresiniz varsa (ve biliyorsunuz, ABD dışında başka ülkeler varsa) tüm bu adres satırı 1, adres satırı 2 vb. Girişler çok can sıkıcıdır.