อะไรคือแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับความยาวและประเภทข้อมูลในฟิลด์ทั่วไปเช่น:
ฯลฯ ....
คำตอบ:
ฉันมีแนวโน้มที่จะสงสัยในแนวปฏิบัติสากลที่ดีที่สุดเพราะส่วนใหญ่ของสาขาเหล่านี้ปีศาจอยู่ในรายละเอียด เพียงเพราะข้อมูลค่อนข้างทั่วไปไม่ได้หมายความว่าแอปพลิเคชันของคุณใช้ข้อมูลในลักษณะเดียวกับที่แอปพลิเคชันอื่นใช้ นั่นหมายความว่าโมเดลข้อมูลของคุณอาจต้องแตกต่างกันเล็กน้อย
STATEตารางและสร้างความสัมพันธ์กับคีย์ต่างประเทศระหว่างSTATEและADDRESSตาราง แต่ความสามารถในการระบุค่าที่ถูกต้องหมายความว่าคุณกำลัง จำกัด ชุดของที่อยู่ที่ถูกต้องอย่างน้อยให้กับชุดของประเทศที่เฉพาะเจาะจง ไม่เป็นไรสำหรับหลาย ๆ ไซต์ แต่คุณต้องทำงานหนักเพื่อสนับสนุนประเทศใหม่CITYตารางที่มีเมืองที่ถูกต้องและความสัมพันธ์กับคีย์ต่างประเทศระหว่างCITYและกับADDRESSตาราง ในทางกลับกันหากคุณเพียงแค่พยายามส่งมอบผลิตภัณฑ์และคุณไม่สนใจมากหากคุณมีเมืองเดียวกันหลายรุ่นในตารางของคุณให้ผู้ใช้ป้อนข้อความแบบฟรีฟอร์มก็เพียงพอแล้ว แน่นอนถ้าคุณเก็บกุญแจต่างประเทศคุณจะมีจำนวนงานที่พอใช้เพื่อให้แน่ใจว่าคุณมีค่าที่ถูกต้องทั้งหมด แต่มีผลิตภัณฑ์ที่จุดทั้งหมดเป็นที่ บริษัท ได้ทำไปแล้ว (เช่นฐานข้อมูลภาษีการขาย)คุณอาจคาดเดาจากข้อมูลตัวอย่างและผู้ชมที่คาดหวัง ขึ้นอยู่กับตำแหน่งของคุณ
หมายเหตุบางส่วน:
ที่อยู่:
ชื่อ:
หมายเลขโทรศัพท์: รหัสระหว่างประเทศ, ความยาว, มือถือกับเฮ้าส์, อนุญาตให้ใช้มือถือเป็นหมายเลขเท่านั้น
นอกเหนือจากคำตอบที่ดีข้างต้นอย่าลืมรับอักขระ Unicode เพียงเพราะคุณอยู่ในสหรัฐอเมริกาไม่ได้หมายความว่าคุณไม่ต้องการรับตัวอักษรต่างประเทศในคอลัมน์ของคุณ
ที่กล่าวว่าฉันมักจะแนะนำ 50 ตัวอักษรสำหรับชื่อ 320 ควรมากกว่าที่อยู่อีเมลที่เพียงพอ (คุณสามารถตรวจสอบมาตรฐาน ANSI เพื่อให้แน่ใจ) สำหรับข้อผิดพลาดที่อยู่ด้านข้างของความระมัดระวังด้วย 255 ตัวอักษร แม้ว่าคุณจะไม่จำเป็นต้องมีที่อยู่ที่ใหญ่ แต่คุณอาจมี C / O และสิ่งต่างๆเช่นนั้น เมืองควรใหญ่มากมีชื่อเมืองยาว ๆ สำหรับรัฐไปกับตารางเด็กเช่นเดียวกับประเทศ สำหรับรหัสไปรษณีย์อย่าลืมรหัสไปรษณีย์ต่างประเทศซึ่งยาวกว่ารหัสไปรษณีย์สหรัฐฯ เพียงเพราะคุณไม่สนับสนุนระหว่างประเทศคุณยังอาจเป็น มีพลเมืองสหรัฐจำนวนมากที่อาศัยอยู่ในมณฑลต่าง ๆ รวมถึงทหาร
อย่าลืมว่ารัฐควรเป็นทางเลือกเนื่องจากหลาย ๆ ประเทศไม่มีรัฐ
ก้นของฉันกำลังเจ็บจากการนั่งบนรั้วดังนั้นฉันจะทิ้งคำตอบบางอย่างและหวังว่าจะไม่ลงคะแนนให้เป็นการให้อภัย โปรดเสนอคำวิจารณ์ที่สร้างสรรค์
ขั้นต่ำ: 6 (a@g.cn) หรือ 3 ถ้าคุณต้องการติดตามที่อยู่อีเมลโดเมนโลคัล
สูงสุด: 320 254 (RFC)
จำนวนรหัสที่ใช้ในการตรวจสอบความถูกต้องของอีเมลนั้นเป็นบ้าจริงดังนั้นให้สมมติว่ามันถูกต้องหากมันมี "@"
คุณอาจต้องการสรุปที่อยู่อีเมลเป็น "วิธีการสื่อสาร" เพื่อให้คุณสามารถแสดงรายการวิธีการทั้งหมดที่ใช้สื่อสารกับผู้ใช้ได้อย่างง่ายดาย
เพศสามารถเปลี่ยนแปลงได้ตลอดเวลาดังนั้นคุณสามารถติดตามได้ว่ามันสำคัญสำหรับคุณหรือไม่ ติดตามhttp://en.wikipedia.org/wiki/ISO/IEC_5218
NOT_KNOWN(0),
MALE(1),
FEMALE(2),
NOT_APPLICABLE(9);
ฉันจะเอาวิธีที่ถูกออกไปและยึดติดกับที่อยู่ในอเมริกาเหนือ
สะดวกสำหรับประเทศที่เป็นนามธรรมเขตการปกครองเมืองและมณฑลส่วนใหญ่เนื่องจากการเก็บภาษี ภาษีสามารถนำไปใช้ได้หลายระดับดังนั้นหากคุณสามารถกำหนดอัตราภาษีในพื้นที่ทางภูมิศาสตร์ที่เป็นนามธรรมคุณก็จะได้ทอง
GeographicArea :
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)
เพิ่ม line2 และ line3 หากคุณต้องการ
ดู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
บางคนมีหลายชื่อในเวลาเดียวกัน (ตัวอย่างเช่นที่มหาวิทยาลัยของฉันมีนักเรียนชาวเอเชียจำนวนมาก แต่พวกเขาชอบใช้ชื่อที่เป็นที่นิยมมากกว่าในตะวันตก)
บางครั้งคุณต้องติดตามชื่อของผู้คนเมื่อเวลาผ่านไปเช่นชื่อเดิมและชื่อที่แต่งงานแล้ว
คุณต้องการให้บุคคลและองค์กรที่เป็นนามธรรมด้วยเหตุผลที่หลากหลาย
สร้างปาร์ตี้บนโต๊ะ (คีย์หลักตัวใหญ่ id)
สร้างตาราง party_name (รหัสคีย์หลักที่ยิ่งใหญ่, party_id bigint ไม่ใช่ null การอ้างอิงปาร์ตี้ (id), พิมพ์ smallint ไม่ใช่ null อ้างอิง party_name_type (id) - ด้าน, อดีต "หญิงสาว", "ถูกกฎหมาย");
สร้างชื่อตารางชื่อ _component (รหัสคีย์หลัก bigserial, party_name_id ใหญ่ไม่ใช่การอ้างอิงแบบไม่ระบุชื่อ party_name (id), พิมพ์ smallint ไม่ใช่ null การอ้างอิงชื่อ _component_type (id), ชื่ออดีต - ได้รับข้อความที่ไม่ใช่โมฆะ);
จากมุมมองที่ต่างออกไปเล็กน้อยจากคำตอบก่อนหน้านี้และดูเหมือนว่าตกลงที่จะพูดคุยเกี่ยวกับ LDAP , RFC 4519 - "Lightweight Directory Access Protocol (LDAP): Schema สำหรับแอปพลิเคชันผู้ใช้"อาจเป็นที่สนใจ
มันอาจมีประโยชน์หากแอปพลิเคชันของคุณจำเป็นต้องแมปไปยังไดเรกทอรีดังกล่าว มิฉะนั้นอาจไม่ปรับให้เข้ากับความต้องการของคุณ
คำจำกัดความเหล่านี้เป็นมากกว่าข้อมูลเกี่ยวกับพวกเขายังเกี่ยวกับตัวดำเนินการบางอย่างที่สามารถใช้ในฟิลด์ ยกตัวอย่างเช่นเป็นpostalAddress caseIgnoreListSubstringsMatchฉันไม่ได้แนะนำว่าคุณควรทำตามสคีมานี้อย่างเคร่งครัด แต่การมองไปที่หลักการอาจน่าสนใจโดยเฉพาะอย่างยิ่งวิธีที่คุณอาจต้องเปรียบเทียบชื่อและที่อยู่ในแอปพลิเคชันของคุณอาจเกี่ยวข้องกับการออกแบบฐานข้อมูลของคุณ
เกี่ยวกับชื่อให้ลองใช้เครื่องหมายคำพูดคู่เพื่อไม่ให้คุณหลีกเลี่ยงเครื่องหมายอะโพสโทรฟีในชื่อไอริชหรืออิตาลี (เช่น O'Hara หรือ D'Amato)
ฉันขอแนะนำให้ใช้ชุดนิพจน์ปกติที่ดีเพื่อให้คุณสามารถส่งออกส่วนต่างๆของฟิลด์ชื่อของคุณ (เช่นชื่อแรกชื่อเล่นจูเนียร์ / อาร์ ฯลฯ )