लंबाई और डेटा प्रकारों पर सामान्य क्षेत्रों में सबसे आम सर्वोत्तम अभ्यास क्या हैं:
आदि....
जवाबों:
मुझे सार्वभौमिक सर्वोत्तम प्रथाओं के किसी भी सेट पर बहुत संदेह होगा, क्योंकि इन क्षेत्रों में से अधिकांश के लिए, शैतान विवरण में है। सिर्फ इसलिए कि जानकारी अपेक्षाकृत सामान्य है इसका मतलब यह नहीं है कि आपका एप्लिकेशन डेटा का उपयोग उसी तरह से करता है जैसे अन्य एप्लिकेशन इसका उपयोग करते हैं। इसका मतलब है कि आपका डेटा मॉडल थोड़ा अलग होना चाहिए।
STATEतालिका बनाने STATEऔर ADDRESSतालिकाओं के बीच एक विदेशी कुंजी संबंध बनाने के लिए समझ में आता है । लेकिन मान्य मानों की पहचान करने की क्षमता का अर्थ है कि आप कम से कम देशों के विशेष पते पर मान्य पते के सेट को सीमित कर रहे हैं। यह कई साइटों के लिए ठीक है, लेकिन फिर आपको एक नए देश का समर्थन करने के लिए थोड़ा काम करना होगा।CITYमान्य शहरों CITYऔर ADDRESSतालिकाओं के बीच एक विदेशी कुंजी संबंध के साथ तालिका। दूसरी ओर, यदि आप केवल एक उत्पाद वितरित करने की कोशिश कर रहे हैं और आप बहुत परवाह नहीं करते हैं यदि आपके टेबल में एक ही शहर के विभिन्न संस्करण हैं, तो उपयोगकर्ता को फ्री-फॉर्म दर्ज करने के लिए पर्याप्त है। बेशक, यदि आप विदेशी कुंजी जमा कर रहे हैं, तो आपके पास यह सुनिश्चित करने के लिए उचित मात्रा में काम होगा कि आपके पास सभी वैध मूल्य हैं। लेकिन ऐसे उत्पाद हैं जहां पूरे बिंदु यह है कि कंपनी ने पहले ही वह काम (यानी बिक्री कर डेटाबेस) कर दिया है।आप नमूना डेटा और अपेक्षित दर्शकों के आधार पर भी अनुमान लगा सकते हैं। यह आपके स्थान पर निर्भर करता है।
कुछ नोट:
पते:
नाम:
फ़ोन नंबर: अंतर्राष्ट्रीय कोड, लंबाई, मोबाइल बनाम घर, मोबाइल को केवल नंबर की अनुमति दें
उपरोक्त महान उत्तरों के अलावा, यूनिकोड वर्णों को स्वीकार करना न भूलें। सिर्फ इसलिए कि आप अमेरिका में हैं इसका मतलब यह नहीं है कि आप विदेशी पात्रों को अपने कॉलम में स्वीकार नहीं करना चाहते हैं।
उन्होंने कहा, मैं आमतौर पर नामों के लिए 50 वर्ण सुझाता हूं। एक ईमेल पते के लिए 320 पर्याप्त से अधिक होना चाहिए (आप सुनिश्चित करने के लिए एएनएसआई मानक की जांच कर सकते हैं)। 255 वर्णों के साथ सावधानी की ओर पते की त्रुटि के लिए। हालांकि आपको शायद कभी भी इस पते की आवश्यकता नहीं होगी कि आप सी / ओ लाइनों और उस तरह के सामान को शामिल कर सकते हैं। शहर बहुत बड़ा होना चाहिए, वहाँ कुछ बहुत लंबे शहर के नाम हैं। राज्य के लिए बाल तालिका के साथ जाना, देश के साथ भी। ज़िप कोड के लिए अंतर्राष्ट्रीय डाक कोड के बारे में मत भूलना जो यूएस ज़िप कोड से अधिक लंबे हैं। सिर्फ इसलिए कि आप अंतरराष्ट्रीय समर्थन नहीं करते हैं आप अभी भी हो सकते हैं। बहुत सारे अमेरिकी नागरिक हैं जो सैन्य लोगों सहित विभिन्न काउंटियों में रहते हैं।
यह मत भूलो कि राज्य वैकल्पिक होना चाहिए क्योंकि कई देशों में राज्य नहीं हैं।
मेरे चूतड़ फैंस के बैठने से गदगद हो रहे हैं, इसलिए मैं बस कुछ जवाब देने की कोशिश कर रहा हूं और उम्मीद है कि वे गुमनामी में न पड़ जाएं। कृपया रचनात्मक आलोचना की पेशकश करें।
मिनट: 6 (ए। ए। एन।)। या 3 यदि आप स्थानीय डोमेन ईमेल पतों को
अधिकतम ट्रैक करना चाहते हैं : 320 254 (RFC)
एक ईमेल को मान्य करने के लिए कोड की मात्रा वास्तव में पागल है, तो चलो मान लें कि यह "@" है तो यह वैध है
आप एक ईमेल पते को "संचार विधि" के रूप में अमूर्त करना चाह सकते हैं, ताकि आप आसानी से उन सभी तरीकों को सूचीबद्ध कर सकें जिनके साथ उपयोगकर्ता को संवाद करना है।
समय के साथ लिंग बदल सकता है, इसलिए आप ट्रैक कर सकते हैं कि यदि यह आपके लिए महत्वपूर्ण है। Http://en.wikipedia.org/wiki/ISO/IEC_5218 का अनुसरण करें
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);
मैं सस्ता रास्ता निकालने वाला हूं और उत्तरी अमेरिकी पतों पर टिकूंगा।
यह ज्यादातर देशों, डिवीजनों, शहरों और काउंटियों के लिए सुविधाजनक है, जो ज्यादातर कराधान के कारण हैं। कर कई स्तरों पर लागू हो सकते हैं, इसलिए यदि आप किसी अमूर्त भौगोलिक क्षेत्र में कर की दर को इंगित कर सकते हैं, तो आप सुनहरे हैं।
भौगोलिक स्थिति :
id: int
type: {country, division, county, city, indian reservation}
name: varchar(45) [1]
abbreviation: nullable varchar(4)
parent_id: nullable int
पता :
id: int
postal_area_id: int, references GeographicArea
county_or_city_id: int, references GeographicArea
street_address: varchar(255)
suite: nullable varchar(255)
यदि आवश्यक हो तो लाइन 2, और लाइन 3 जोड़ें।
Http://en.wikipedia.org/wiki/Address_(geography) देखें
अब, एक पता एक पता है। कई लोग एक पते पर रह सकते हैं, और एक व्यक्ति के पास एक ही समय में और समय के साथ कई पते हो सकते हैं, इसलिए आपको इसके लिए कई-कई तालिका की आवश्यकता होती है।
PartyAddress
party_id: int references Party
address_id: int references Address
purpose: {home, work, ...}
यदि समय के साथ ट्रैकिंग बंद हो जाए तो एक from_dateऔर अशक्त जोड़ें to_date।
एक पार्टी में कई फोन नंबर हो सकते हैं और एक फोन नंबर का उपयोग कई लोग कर सकते हैं। फोन नंबर का उपयोग फैक्स, टेलीफोन कॉल, मोडेम आदि के लिए किया जा सकता है और इसमें एक्सटेंशन हो सकते हैं। ये सभी समय के साथ बदल सकते हैं।
फ़ोन नंबर
id: int
value: varchar(15) - the max allowed by the ITU
न्यूनतम 3 हो सकता है ("911" के लिए), या शायद 7 ("310-4NET"), जो एक विशेष प्रकार की स्थानीय संख्या है जो आपको क्षेत्र कोड डायल करने की अनुमति नहीं देती है)
यदि आवश्यक हो, तो आप इसे देश कोड में विभाजित कर सकते हैं।
आपको http://en.wikipedia.org/wiki/E.164 मानक का उपयोग करना चाहिए
PartyPhoneNumber
party_id: int references Party
phone_number_id references PhoneNumber
extension: nullable varchar(11) - ITU max
purpose: {home, work, fax, modem, ...}
नाम कठिन हैं। यहाँ पर क्यों:
कुछ लोगों का कानूनी नाम केवल एक शब्द में है http://en.wikipedia.org/wiki/List_of_legally_mononymous_people
कुछ लोगों के नाम कई शब्दों के साथ हैं http://en.wikipedia.org/wiki/Wolfe%2B585,_Senior
कुछ लोगों के एक ही समय में कई नाम हैं (उदाहरण के लिए, मेरे विश्वविद्यालय में कई एशियाई छात्र हैं, लेकिन वे "अधिक पश्चिमी नाम" पसंद करते हैं)
कभी-कभी, आपको समय के साथ लोगों के नामों को ट्रैक करने की आवश्यकता होती है, जैसे कि नाम और विवाहित नाम।
आप कई अच्छे कारणों के लिए व्यक्तियों और संगठनों को सार करना चाहते हैं
टेबल पार्टी (आईडी बिगसेरियल प्राथमिक कुंजी) बनाएं;
टेबल पार्टी_नाम बनाएं (आईडी बिगसेरियल प्राइमरी की, पार्टी_आईडी बिगिंट नॉट रेफरेंस पार्टी (आईडी), टाइप स्मॉलिंट नॉट रेफरेंस पार्टी_name_type (आईडी) --elered, ex "maiden", "legal");
तालिका name_component (id bigserial Primary key, party_name_id bigint not null reference party_name (id) बनाएँ, टाइप करें smallint not null reference name_component_type (id), --elered ex "दिए गए" name text not null);
पिछले उत्तरों की तुलना में थोड़ा अलग दृष्टिकोण से, और चूंकि LDAP , RFC 4519 के बारे में बात करना ठीक लगता है - "लाइटवेट डायरेक्ट्री एक्सेस प्रोटोकॉल (LDAP): स्कीमा फॉर यूजर एप्लिकेशन" रुचि का हो सकता है।
यदि आपके एप्लिकेशन को ऐसी निर्देशिका में मैप करने की आवश्यकता हो तो यह उपयोगी हो सकता है। अन्यथा, यह शायद आपकी आवश्यकताओं के अनुकूल नहीं है।
ये परिभाषाएँ केवल डेटा के बारे में अधिक हैं, वे कुछ ऑपरेटरों के बारे में भी हैं जिनका उपयोग खेतों पर किया जा सकता है। postalAddress, उदाहरण के लिए ए caseIgnoreListSubstringsMatch। मैं सुझाव नहीं दे रहा हूं कि आपको इस स्कीमा का सख्ती से पालन करना चाहिए, लेकिन सिद्धांतों को देखना दिलचस्प हो सकता है, विशेष रूप से आपको अपने आवेदन में नाम और पते की तुलना कैसे करनी पड़ सकती है, यह आपके डेटाबेस के डिजाइन के लिए प्रासंगिक हो सकता है।
नामों के बारे में, दोहरे उद्धरण चिह्नों का उपयोग करने पर विचार करें ताकि आपको आयरिश या इतालवी नामों (जैसे, ओ'हारा या डी'मैटो) में धर्मत्याग से बचना न पड़े।
मैं भी उपयोग करने के लिए नियमित एक्सप्रेशन का एक अच्छा सेट प्राप्त करने की सलाह दूंगा, ताकि आप अपने नाम फ़ील्ड के कुछ हिस्सों (जैसे, पहले प्रारंभिक, उपनाम, जूनियर / सीन, आदि) का उत्पादन कर सकें।