Sokak adreslerini ayrı sütunlara bölerek hangi problemler çözülür?

Yazılım geliştiriciler için masaları ve ilişkileri tasarlayan bir ekibimiz var. Kuruluşumuzda, 3NF normalizasyonunun uygulanması konusunda oldukça katılar - dürüst olmak gerekirse, kuruluşumuzun büyüklüğü ve ihtiyaçların veya müşterilerimizin zaman içinde nasıl değiştiği konusunda aynı fikirdeyim. Tasarım kararlarının ardındaki nedenler hakkında net olmayan tek bir alan var: adresler.

Bu daha çok ABD’deki adreslere odaklanırken, bunun bunu yapan herhangi bir ülke için geçerli olabileceğini düşünüyorum. Bir adresin her parçası adres tablosunda kendi sütununu alır. Örneğin, bu korkunç ABD adresini alın:

Attn: Jane Doe
485 1/2 N Smith St SW, APT 300B
Chicago, IL 11111-2222

Bu şekilde veritabanında bölünmüş olur:

• Sokak numarası: 485
• Sokak kesri: 1/2
• Sokak ön yöne: N (Kuzey)
• Sokak adı: Smith
• Sokak tipi: ST (Sokak)
• Yön sonrası sokak: SW (Güneybatı)
• Şehir: Chicago
• Devlet: IL (Illinois)
• Posta kodu: 11111
• Posta Kodu: 2222
• Ülke (ABD olarak kabul edildi)
• Dikkat: Jane Doe
• Posta Kutusu: NULL
• Konut tipi: APT (Daire)
• Konut numarası: 300B

Ve kırsal yollar ve sözleşme yollarıyla ilgili birkaç sütun daha olacaktı. Ayrıca, özel uygulamamızın içinde birkaç uluslararası adres olması muhtemeldir. Veri modelleyicileri, uluslararası adreslere özel, normal satır 1, satır 2 alanları olacak sütunlar ekleyeceklerini söyledi.

İlk başta bunun WAY denize düştüğünü düşündüm. İnternette tekrar tekrar araştırma yapmak, adres satırı 1, 2, 3 ve muhtemelen 4'ü kullanıp ardından şehri, bölgeyi ve posta kodunu ayırmayı ifade eder. Bu taneliğin yararlı olduğu yeni uygulamamız için tek kullanımlık bir vakamız var. Kullanıcının yinelenen bir işletme oluşturmadığını doğrulamalıyız ve adresin kontrol edilmesi doğrulamalardan biridir. Biz olabilir o adres satırına 1 ve 2 ile çalışmak için, ama daha zor olurdu.

Özel uygulamamızda ise, işletmeler ve insanlar için (fiziksel, postalama, nakliye vb.) Çok sayıda adres saklamamız gerekiyor. Biz olabilir yazdırılabilir form mektuplar oluşturmak gerekir, ama bu gereklilik kadar ele edilmemiştir.

Kuruluşumuzdaki uygulamaların desteklenmesi gereken diğer bazı şeyler:

• Denetim (tam tarih tablolarıyla birlikte)
• Posta etiketlerini yazdırma
• Basılı formların oluşturulması
• Raporlama (ulusal ve bölgesel hükümetler için)

Uygulamamız diğer tüm uygulamaların yaptığı her şeyi yapmıyor olabilirken, adresleri birden fazla bileşene bölmek çalıştığım işletme standardıdır . Başvurumuzun bundan faydalanıp faydalanmamasına bakılmaksızın, bunu yapmak zorundayız.

Yarı ile ilgili StackOverflow sorusu: Kapatılan, ancak adreslerin ne kadar zor ayrılabileceğini gösteren iyi bir Adres Ayrıştırıcı nerede .

Tasarım kararlarını daha iyi anlayabilmem ve müvekkilimizi bu fikre satabilmem için

Sokak adresini ayrı sütunlara bölerek hangi problemler çözülür?

Böyle bir sistemi uygulayan herkes için bonus puan çünkü problemlerle karşılaştılar.

Bölünerek çözülebilecek problemler arasında

Doğrulama İsmin herhangi bir kısmı bir ana liste ile karşılaştırılabilir. Eşleşmeyenler reddedilebilir. Posta kodu / posta kodu açık bir örnektir. Bunlar bağımsız bir otorite tarafından verilir ve korunur. Sadece geçerli olanlar otorite tarafından verilenlerdir.

Sıralama ve Seçme Posta, bir süredir organize edilmiş olan teslim hizmetine verilirse posta ücretlerinin düşürüldüğü durumları gördüm. İlgili sütunlara sahip olmak somut bir işletme değeri üretir.

Analiz Siparişlerin nereye gittiğini, coğrafi olarak hiyerarşik bir şekilde bilmek yararlı olabilir. Bu, satış girişimlerini, ürün geliştirmeyi veya komisyon ödemelerini vb.

Kod Çoğaltma Bir kuruluştaki tüm uygulamaların aynı veri modelini benimsemesini sağlayarak (en karmaşık tüketicinin), tek bir kod tabanı kurum çapında kabul edilebilir ve tutarlı bir şekilde korunabilir. Sonsuz bir şekilde çoğaltılmış saç yarılmasından kaçınılabilir veya en azından pervane başlarına delege edilebilir. Kuruluşun farklı bölümleri tarafından tutulan adresler tutarlı bir şekilde güncellenebilir. Müşteri hizmetleri ve memnuniyeti arttırılabilir. Geliştirme çabası, bir sistemin eşsiz, yüksek değerli kısımlarına odaklanabilir.

Yasal Meseleler Yasalar ve vergiler yargı yetkisine göre değişir. Ayrıntılı adres değerlerini ayrı ayrı yakalayarak, işlem verilerine uyumluluk gereksinimlerine çapraz referans vermek daha kolaydır.

Çoğaltma Bir öğeyi bir sonraki satıra taşıyarak veya bazı parçaları yeniden sıralayarak metin olarak tutulan adresleri taklit etmek kolaydır. Tamamen ayrıştırılmış adresleri karşılaştırmak daha kolaydır. Bu, basit bir veri kalitesi sorunu olabilir veya örneğin birden fazla kabuk şirketi aynı teslimat adresine büyük siparişler verirse veya kısa sürede birçok dağınık bölgeye dağıtım yapmak için bir kredi kartı kullanılırsa, uyumluluk veya kredi etkileri olabilir.

Ayrı bir şekilde tutulan parçaları biçimlendirmek , mevcut ihtiyaca uyan moda ne şekilde birleştirilebilir. Örneğin, uzun ince baskı etiketleri ucuz hale gelirse, bunları kullanmak için yeniden biçimlendirebilirsiniz.

Elbette bunların hiçbiri herhangi bir özel başvuru için geçerli olmayabilir. Bu türdeki veriler, toplandıklarında kaynağında ayrıştırmak ve doğrulamak, analiz sonrası olacağından çok daha kolaydır. Dolayısıyla YAGNI bile, az bir maliyet ve potansiyel büyük bir gelecek tasarruf için ekstra çaba sarf etmek daha iyi olabilir.

Sonunda, insan faktörünü göz ardı etmem. Veri modeli, veri modelleyicileri tarafından üretilir. Yaptıkları şey bu. Bu onların mesleği. Bunu sadece bir BLOB'a atmanı söylemeyecekler, değil mi?

Bir yayıncılık şirketi için 7 yıl boyunca yazılım geliştirdim ve uğraştığımız en büyük sorunlardan biri abonelik listelerinde sokak adreslerini ayrıştırmaktı. Adresleri farklı alanlara ayırmak yararlıdır, ancak hiçbir zaman, HİÇ , insan beyninin tasarlayabileceği her türlü adres formatı ve bileşen patolojik sapması için tasarım yapamazsınız.

Her yörenin tuhaflıkları olabilir ve bu sadece ABD’de. Diğer ülkelerde atmak ve her adres ayrıştırmak isteyen herhangi bir yaklaşım için işler çok hızlı bir şekilde yönetilemez hale gelir. Sadece iki örnek:

İspanya'da, cadde numarası her zaman cadde adı ve virgülün ardında gelir ve birçok adres, 1 ° veya 3ª gibi bir sıra numarası içerir; soldan sonra "sol" ("Izda" anlamına gelen kısaltmalar) merdivenlerden kalk), "doğru" ("Dcha") veya başka olasılıklar. Şimdi bu ilginçliği, adresler için farklı tarihsel geleneklere sahip farklı ülke ve bölgelerle çarpın ... (Japonya? Kırsal İngiltere? Kore? Çin?)

Portland, OR'da, şehri NW, NE, SW ve SE kadranlarına ayıran NS ve EW eksenleri var (hem de bir N "kadranı", ancak ben dalıyorum). NS caddeleri bu eksenden artan bir şekilde Doğu ve Batı olarak numaralandırılmıştır ve EW sokaklarındaki adresler, NS sokak numarası ile sayının "yüz bloğu" olarak belirlenir (yani, 11. ve 12. caddelerin arasındaki EW caddesindeki bir evin bir numarası olacak) 1123 gibi). ABD adresleri için oldukça standart şeyler.

Arada sen gibi bir Portland adresi girmek 0205 SW Nebraska St . Önde gelen sıfır? O NE LAN? integer"Sayı" evi için köşeme gidiyor .

Izgara kurulduğunda, NS ekseni Willamette nehri tarafından tanımlandı. Nehrin doğusundaki her şey NE veya SE, NW veya SW nehrinin batısındaydı. Şehir güneye doğru büyüdükçe, nehrin Doğu'ya geldiği için uygunsuz bir gerçekle karşılaştılar, bu yüzden Güney eksenini yansıtırken, nehrin "Batı" tarafında ancak eksenin doğusunda olan bu problemli alana sahip oluyorsunuz. Çözüm, eksen çizgisinden doğuya doğru artan sayılarla eksi bir işaret olarak öndeki bir sıfır ekleyecekti .

Yerinde olsam, nihai sistemi tasarlama umudundan vazgeçirdim. Tüm olasılıkları karşılayamazsınız ve insanlık daha önce gelişmemiş topraklara doğru ilerledikçe yenileri yaratılacak.

ABD adresleri için, USPS’nin adres standardizasyonunda neler yaptığını inceleyin ve house_numbersütunu bir yapmayı unutmayın varchar. Bu sırada 1634 EN Fort Lane Ave'yi nasıl ayrıştıracağınızı öğrenin .

Dünyanın geri kalanı için, muhtemelen ortaya çıkması muhtemel olanın% 80-90'ını kapsayacak ek alanlar soyutlamaya ve gerekli olduğunda her şeyi halledebilecek bir dizi yorumlanmamış alan sunmaya çalışacağım. Yani, ayrıştırıcınız bir adresi ele almayı başaramazsa, ayrıştırılmadan kaydedin ve işaretlendi. Bir adresi ayrıştırmayı başarırsanız, çeşitli alanları bulduğunuz sırayı hatırladığınızdan emin olun, böylece onu teslim edilebilir bir şey haline getirebilirsiniz.

En önemli alanın posta kodu olacağını söyleyecektim, ama bu bile pek çok yerde verilen bir şey değil .

İyi şanslar. Bu eğlenceli ve son derece sinir bozucu bir çaba olabilir, ancak akıl sağlamanın anahtarı ne zaman vazgeçmeyi bilmek ve sadece girdiyi ayrıştırılmamış olarak veya orijinal girdiyle kısmen yedeklenmiş olarak ayrıştırmaktır.

Tüm tasarım soruları gibi, oldukça "nitelikli" özelliklerine de sahip. Veri hikayenize - verinin nasıl toplandığına, nasıl kullanıldığına, nasıl güncelleştirildiğine vb. Bağlıdır. Bütün yorumlarım nasıl yapılır yanıtları değil tartışma noktaları olarak alınmalıdır.

Bir adres doğrulama servisi kullanmaktan, kendiniz için bir tane oluşturmaya çalışmaktan daha fazla fayda sağlayabilirsiniz. Maliyetleri yüksek olsa da, bu tür birçok hizmet önemli posta indirimleriyle geliyor.

Tabii ki, burada bazı veri hikayeleri için bir uzlaşma var. Ayrıştırılmış adres parçalarına devam edebilir ve birleştirilmiş adres için hesaplanmış bir sütun (muhtemelen sütunlar kümesi) oluşturabilirsiniz. Bu, tüm normal uyarıların ima edildiği şekilde bir uygulama cevabıdır.

Ayrıştırılmış adres tasarımını uyguladım. Veri kalitesi ve veri işleme ihtiyaçları için buna kesinlikle ihtiyacımız vardı. Ancak bu fiziksel adresleri, posta adresleri, sanal adresleri vb. Olan bir işti.

Ortaya çıkabilecek diğer sorun, farklı posta hizmetlerinin aynı bilgilerin farklı formatlarda / siparişlerde / vb. Sunulmasını gerektirmesidir. Böylece parçaların modellenmesi aynı bilginin çeşitli format ve düzenlerde sunulmasını destekler.

Son olarak, uluslararası verileri desteklemek için uluslararası işletme operasyonlarına ihtiyacınız yoktur. ABD merkezli işletmelerin bile uluslararası adresleri desteklemesi gerekiyor. Buna asla sahip olmayacağınızı varsaymak çok büyük bir veri hatası. Müşteriler taşınır, satıcılar genel merkezi değiştirir, satıcı iletişim bilgileri ABD’de genel merkezi olsa bile uluslararası olabilir. Mevcut sistemleriniz bu hatayı yapmış olsa bile, bunu ilerletmek istemezsiniz.

Graham Rhind'in yazdıklarını ve bloglarını tavsiye ederim. Her türden adresler ve bunlarla ilişkili değişimler hakkında veri alanındaki uzmandır.

_{* Tüm söylediklerim brüt bir genelleme. Bir tasarım çözümüne gelmek için birkaç saat süren bir sohbetle sonuçlanabilecek çok fazla soru var. Muhtemelen bazı resimler ve bazı veri profilleri de. Ve sonra adresleri hakkında gerçekten ilginç veri hikayeleri.}

Tamamen bir kenara bırakarak, insanların sağladığı öngörülemeyen anlamsız kesimi doğru bir şekilde ayrıştırma zorluğunu bir kenara bırakın, ayrıştırmanın yararı , gruplandırma ve sıralama için size boyutlar vermesidir. Örneğin posta kodu. Ancak, belirli bir boyut ayrıştırmanın, o boyutta gruplandırmanız veya sıralamanız gerekene kadar herhangi bir getirisi yoktur .

Ne olduğunu zaten bir adres? Bir yer tanımlayıcısı olduğu için iyi bir dava açabilirsiniz, ancak teslimat talimatlarını vermek için eşit derecede iyi bir dava yapabilirsiniz - "Çimento fabrikasından caddeden aşağı". Avustralya'da insanlar posta kodlarının konum tanımlayıcıları olduğunu düşünüyorlar, ancak değiller, yönlendirme kodları - teslimat talimatları. 4702, denizden 300km içerideki bir maden kasabası olan Emerald'a uzanan bir bölgeye hizmet veren büyük bir dağıtım düğümü olan Rockhampton Posta Merkezidir.

Konumları tanımlamak istiyorsanız, Bing ve Google doğrudan ayrıştırılmamış dizeden GPS koordinatlarına coğrafi olarak kodlanabilir; bu, ayrıştırılmamış dizeyle birlikte küçük, basit bir tabloda saklanabilir. Sürekli olarak iyi sonuçlar alma şansı olan tek genel yaklaşımı kullanırlar: doğrulanmış sonuçların devasa bir veri tabanı ile sıralanmış ağırlıklı kısmi eşleşme.

Teslimat talimatlarını istiyorsanız, herhangi bir şey içerebileceği için hala kullanılmamış dizgeyi saklamanız önerilmektedir .

Her iki durumda da ayrıştırılmamış dizeyi korumayı önerdiğime dikkat edin. O yüzden

• kendi başına işe yarar
• bir gün nasıl ayrıştırılacağını çözeceksin
• Bundan birkaç gün sonra, nasıl doğru şekilde ayrıştırılacağını çözeceksiniz.
• bu asla bitmez

Muhtemelen bir adres her zaman en az bir konum tanımlayıcı içeren teslimat talimatlarıdır . "123 Main st, Emerald 4702" adresinde yazılan bir harf üç konumu kodlar: Rockhampton, Emerald'ın kuzey kesiminde bulunan RMC ve cadde adresi. Rockhampton postanesi sadece RMC'ye gönderecek. RMC bunu Emerald postanesine gönderecek ve Emerald postanesi umarım 123 Ana caddeyi nerede bulacağını bilir.

Hollanda'da da olsa böyle bir sistemi daha önce uyguladım. Mesele şu ki, bu tür bilgiler düşündüğünüzden daha fazla şekilde değişebilir. Sokaklar yeniden adlandırılır, şehirler birleştirilir vb. Adresleri tek bir dize olarak ayrıştırmadan bu tür bilgileri güncelleyebilmek çok güzel.

Posta kodu / posta kodu ayırma, bina adı, yol adı mantıklı olabilir. Ama sonra “şehir”, “alan” vb. Eklemeye başladığınızda, sadece satır1, satır2 vb. İle karşılaştırmalı olarak sorgulanabilir hale gelir. İlçe alanına "köy" adı mı yazılmalı, yoksa yerel şehir şehir alanlarına yerleştirilirken yol adının altındaki satıra mı giriyor? (Bir kasaba yerine bir köy yaşadıkları yeri çağırırsanız bazı insanlar kırılır, aynı yerde yaşayan diğer insanlar da köy yerine bir kasaba çağırırsanız kırılır!)

Bu nedenle, fantezi bir şey yapmaya çalışmak kullandığınız adres doğrulama sisteminden daha iyi değildir. Ama daha da kötüleşiyor. İngiltere'de TÜM adreslerin bir posta kodu olması gerekir, ancak henüz posta kodu bir ev inşa edilmeden bir süre öncesine kadar tahsis edilmez …… Bu nedenle, bir sistem adres hakkındaki her kuralın ihlal edilmesine izin vermek zorundadır!

Başka cevaplarda daha önce belirtilen sorunlara ek olarak, bazı dillerde - özellikle de Germen - sokak isimleri birleşme eğilimindedir. Örneğin, birçok Alman kasabasında / şehrinde, tren istasyonuna giden caddede (Bahnhofstrasse), (tren / tren istasyonunda "Strasse", cadde anlamında "Bahnhof") yaygındır. Elbette bu iki bileşeni birbirinden ayırabilirsiniz, ancak şimdi bunları bir araya getirmek istiyorsanız (programatik olarak) çekişme sorunlarıyla karşılaşıyorsunuz.

Veya, "romantizm" veya Latin dillerinde, sık sık "Rue de la Pais" veya "Boulevard des Champs-Élysées" şeklinde cadde adlarına sahipsiniz. Şimdi karışımda bir edat ("de") ve belirli bir makale ("le" veya "la") var - ve bunlar birleştirilebilir. Sokak tipinin veya sokak adının bir parçasını mı temsil ediyorlar? (Muhtemelen onları bir yere koymanız gerekir, aksi halde tekrar çekime girersiniz.)

Bir zamanlar böyle bir şey modelledim. Ancak, orta büyüklükteki bir üniversitenin (ABD'de) konut mülk bakım ofisi için çok küçük bir uygulama oldu. Aşağıdaki nedenlerden dolayı adresleri çok ayrıntılı hale getirdim:

• Bölgede aynı adı taşıyan ancak farklı bir cadde "tip" olan caddeler vardı (örneğin, "Woods Avenue" vs "Woods Court").
• Kullanıcılar bakım işini optimize etmek istiyorlardı, örneğin aynı blokta aynı anda ele alınabilecek iki veya daha fazla servis talebi varsa.
• Kullanıcılar aynı binadaki farklı birimler (apartmanlar) arasındaki sorunları ilişkilendirebilmek istedi - örneğin birden fazla apartman soğuk sıcaklıklar veya yeterince sıcak su bildirmediyse.

... ve artık hatırlamadığım diğer sebepler. (Bu 1980'lerin sonlarındaydı.)

Ve yine, bu yalnızca mantıklı geldi çünkü ele alınacak oldukça az sayıda adres vardı (ve adres biçimlendirme kuralları). Bu yaklaşımın, ABD adresleriyle sınırlı olsa bile, başka cevaplarda verilen sebeplerden dolayı ölçekleneceğine inanmıyorum.