Aşağıdaki gibi ortak alanlarda uzunluk ve veri türü konusunda en yaygın kullanılan uygulamalar nelerdir:
vb....
Yanıtlar:
Herhangi bir evrensel en iyi uygulamalardan çok şüphelenmeye meyilliyim çünkü bu alanların çoğu için şeytan ayrıntıda gizli. Bilginin nispeten yaygın olması, uygulamanızın verileri diğer uygulamaların kullandığı gibi kullandığı anlamına gelmez. Bu, veri modelinizin biraz farklı olması gerekebileceği anlamına gelir.
STATEtablo oluşturmak ve STATEve ADDRESStablolar arasında yabancı bir anahtar ilişki oluşturmak anlamlı olur . Ancak geçerli değerleri belirleme yeteneği, geçerli adres kümesini en azından belirli bir ülke grubuyla sınırladığınız anlamına gelir. Pek çok site için sorun değil, ancak yeni bir ülkeyi desteklemek için biraz iş yapmanız gerekiyor.CITYgeçerli şehirler ile tablo CITYve ADDRESStablolar arasında yabancı bir anahtar ilişkisi . Öte yandan, yalnızca bir ürünü teslim almaya çalışıyorsanız ve aynı şehrin çeşitli sürümlerinin masanızda olmasına dikkat etmiyorsanız, kullanıcının serbest biçimli metni girmesine izin vermek yeterlidir. Elbette, yabancı anahtarlar saklıyorsanız, geçerli tüm değerlere sahip olduğunuzdan emin olmak için yeterli miktarda işiniz olacaktır. Ancak asıl mesele, şirketin zaten bu işi yapmış olduğu ürünlerdir (örneğin satış vergisi veritabanları).Ayrıca örnek verilere ve beklenen izleyicilere dayanarak tahmin edebilirsiniz . Bulunduğunuz yere bağlı.
Bazı notlar:
Adresler:
İsimler:
Telefon numarası: Uluslararası kod, uzunluk, cep vs ev, cep telefonu olarak yalnızca sayı olarak izin ver
Yukarıdaki harika cevaplara ek olarak, unicode karakterleri kabul etmeyi de unutmayın. Sırf ABD’de olduğun için yabancı karakterleri sütunlarına kabul etmek istemediğin anlamına gelmez.
Bununla birlikte, isimler için genellikle 50 karakter öneririm. 320 bir e-posta adresi için fazlasıyla yeterli olmalıdır (emin olmak için ANSI standardını kontrol edebilirsiniz). 255 karakter ile dikkatli tarafında adres hatası için. Muhtemelen asla o kadar büyük bir adrese ihtiyaç duymayacak olsanız da, C / O satırlarını ve bunun gibi şeyleri dahil edersiniz. Şehir oldukça büyük olmalı, orada oldukça uzun şehir isimleri var. Devlet için ülkeyle aynı, bir çocuk masası ile gidin. Posta kodu için ABD posta kodlarından daha uzun olan uluslararası posta kodlarını unutmayın. Sırf uluslararası desteklemediğin için hala olabilirsin. Askeri insanlar da dahil olmak üzere farklı illerde yaşayan birçok ABD vatandaşı var.
Pek çok ülkede devlet olmadığı için devletin isteğe bağlı olması gerektiğini unutmayın.
Sersem benim çitin üzerine oturmaktan ağrıyor, ben de bazı cevaplar atacağım ve umudumdan aşağılık oy kullanmamayı umuyorum. Lütfen yapıcı eleştiri sunun.
dak: 6 (a@g.cn). Veya yerel etki alanı e-posta adreslerini
maksimum: 320 254 (RFC) izlemek istiyorsanız, 3
Bir e-postayı doğrulamak için gereken kod miktarı gerçekten çılgıncadır, bu nedenle "@" varsa geçerli olduğunu varsayalım.
Bir e-posta adresini "iletişim yöntemi" olarak soyutlamak isteyebilirsiniz, böylece bir kullanıcıyla iletişim kurmak için tüm yöntemleri kolayca listeleyebilirsiniz.
Cinsiyet zamanla değişebilir, böylece sizin için önemliyse izleyebilrsiniz. Http://en.wikipedia.org/wiki/ISO/IEC_5218 izleyin.
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);En ucuza gidip Kuzey Amerika adreslerine sadık kalacağım.
Çoğunlukla vergilendirme nedeniyle soyut ülkelere, bölgelere, şehirlere ve ilçelere uygundur. Vergiler birçok düzeyde geçerli olabilir, bu nedenle bir vergi oranını soyut bir coğrafi bölgeye yönlendirebilirsiniz, altınsınız.
Coğrafi Alan :
id: int
type: {country, division, county, city, indian reservation}
name: varchar(45) [1]
abbreviation: nullable varchar(4)
parent_id: nullable int Adres :
id: int
postal_area_id: int, references GeographicArea
county_or_city_id: int, references GeographicArea
street_address: varchar(255)
suite: nullable varchar(255) Gerekirse, satır 2 ve satır3 ekleyin.
Http://en.wikipedia.org/wiki/Address_(geography) bakın
Şimdi bir adres bir adres. Birden fazla kişi bir adreste yaşayabilir ve bir kişinin aynı anda ve zaman içinde birden fazla adresi olabilir, bu nedenle bunun için çok sayıda masaya ihtiyacınız vardır.
PartyAddress
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...} Zamanla takip ediyorsanız a from_dateve nullable ekleyin to_date.
Bir tarafın birden fazla telefon numarası olabilir ve bir telefon numarası birden fazla kişi tarafından kullanılabilir. Fakslar, telefon görüşmeleri, modemler vb. İçin bir telefon numarası kullanılabilir ve uzantıları olabilir. Bunların hepsi zaman içinde değişebilir.
Telefon numarası
id: int
value: varchar(15) - the max allowed by the ITU En az 3 ("911" için) veya belki 7 (alan kodunu çevirmenize izin vermeyen özel bir tür yerel numara olan "310-4NET" olabilir)
Gerekirse, bunu ülke koduna vs. ayırabilirsiniz.
Http://en.wikipedia.org/wiki/E.164 standardını kullanmalısınız
PartyPhoneNumber
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...} İsimler zor. İşte nedeni:
Bazı kişilerin içinde tek bir kelimeyle yasal bir adı vardır: http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
Bazı insanlar çok kelimeli isimlere sahiptir: http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
Bazı insanlar aynı anda birden fazla isme sahip (örneğin üniversitemde çok sayıda Asyalı öğrenci var, ancak "tercih edilen" daha Batılı isimleri kullanmaktan hoşlanıyorlar)
Bazen, kızlık soyadı ve evli isimleri gibi insanların isimlerini zaman içinde izlemeniz gerekir.
Bireyleri ve organizasyonları çeşitli iyi nedenlerle soyutlamak istiyorsunuz
masa partisi oluşturun (kimlik büyük birincil anahtarı);
tablo parti_adı oluşturun (kimliği biggerial birincil anahtarı, party_id bigint boş olmayan referans partileri (id), boş olmayan küçük referanslar yazın party_name_type (id) --elided, ex "maiden", "legal");
tablo name_component (kimlik birincil birincil anahtarı, party_name_id bigint boş olmayan referanslar parti_adı (id) oluşturun, smallint olmayan boş referanslar yazın name_component_type (id), - "eskiden" verilen "isim metni boş değil);
Önceki cevaplardan biraz farklı bir bakış açısıyla ve LDAP hakkında konuşmanın uygun görünmediğinden , RFC 4519 - "Hafif Dizin Erişim Protokolü (LDAP): Kullanıcı Uygulamaları için Şema" ilgi çekici olabilir.
Uygulamanızın böyle bir dizine eşlenmesi gerekiyorsa faydalı olabilir. Aksi takdirde, muhtemelen gereksinimlerinize uygun değildir.
Bu tanımlar sadece veriden ibaret değil, aynı zamanda tarlalarda kullanılabilecek bazı operatörlerle de ilgilidir. postalAddress, örneğin bir caseIgnoreListSubstringsMatch. Bu şemaya kesinlikle uymanız gerektiğini önermiyorum, ancak prensiplere bakmak ilginç olabilir, özellikle uygulamanızdaki isim ve adresleri nasıl karşılaştırmanız gerekebileceği, veritabanınızın tasarımıyla ilgili olabilir.
İsimlerle ilgili olarak, çift tırnak işareti kullanmayı düşünün; böylece İrlandaca veya İtalyanca isimlerden (örneğin, O'Hara veya D'Amato) kesme işareti kaçmak zorunda kalmazsınız.
Ayrıca, kullanmak için iyi bir Düzenli İfadeler seti almanızı tavsiye ederim, böylece ad alanlarınızın bazı bölümlerini yazdırabilirsiniz (örneğin, ilk harf, takma ad, Jr / Sr, vb.).