มาตรฐานตามข้อเท็จจริงสำหรับบันทึกข้อมูลลูกค้า [ปิด]

ขณะนี้ฉันกำลังประเมินโครงการใหม่ที่อาจเกิดขึ้นซึ่งเกี่ยวข้องกับการสร้างฐานข้อมูลลูกค้าทั่วไป (userid, pwd, ชื่อ & นามสกุล, อีเมล, ที่อยู่, telfnr ... ) ณ จุดนี้ความต้องการมีการกำหนดคร่าวๆเท่านั้น

ฐานข้อมูลลูกค้าคาดว่าจะอยู่ในบันทึก O (ล้านรายการ) ในการคำนวณตัวเลขแบ็คเอนด์สำหรับการปรับขนาดฐานข้อมูลและประเมินตัวเลือกฐานข้อมูลและสถาปัตยกรรมที่เป็นไปได้ฉันกำลังมองหามาตรฐานที่แท้จริงสำหรับบันทึกประเภทนี้ โดยเฉพาะอย่างยิ่งขนาดมาตรฐานของทุกสาขา (ชื่อ, นามสกุล, ที่อยู่, ... ) หรือเฉลี่ยปกติสำหรับลูกค้าบันทึกง่ายจะข้อมูลที่ดี

เมื่อมีเว็บไซต์อีคอมเมิร์ซจำนวนมากออกมาควรมีการกำหนดค่าทั่วไปบางประเภทที่สามารถนำมาใช้ซ้ำได้และหลีกเลี่ยงการประดิษฐ์ล้อเลื่อนอีกครั้ง

ความคิดใด ๆ

---- แก้ไข ----

คำตอบดูเหมือนว่าจะนำไปสู่การใช้บันทึกลูกค้ามาตรฐานและการออกแบบของคุณเอง ฉันต้องการเน้นว่าจุดเน้นของคำถามนี้คือการค้นหาการอ้างอิงสำหรับการปรับขนาดเขตข้อมูลสำหรับวัตถุลูกค้าและหลีกเลี่ยงการหาสิ่งนั้นด้วยตัวเอง (ฉันได้เน้นส่วนนั้นในข้อความต้นฉบับ - ตอนนี้เป็นตัวหนา -)

สิ่งที่ดีเกี่ยวกับมาตรฐานคือคุณมีให้เลือกมากมาย - Andrew Stuart Tanenbaum

สิ่งต่าง ๆ เช่นนี้มีความเฉพาะเจาะจงสำหรับลูกค้าและอุตสาหกรรมสิ่งทั่วไปจะรวมทุกอย่างและอ่างล้างจานในครัว โดยเฉพาะอย่างยิ่งรูปแบบประเภท EDI พวกเขาถูกกำหนดโดยทั่วไปในช่วงทศวรรษหรือมากกว่านั้นในกรณีส่วนใหญ่และรวมทุกอย่างทุก บริษัท ในคณะกรรมการที่เคยต้องการ พวกเขาควรจะเป็นอุตสาหกรรมทั่วไปและพวกเขากลายเป็นอุตสาหกรรมที่เฉพาะเจาะจงและเปราะบางอย่างยิ่ง

ไม่มีถนนหลวงสำหรับการออกแบบหรือข้อมูลที่คุณต้องการ ทำเวลาและความพยายามเพื่อให้ได้ข้อกำหนดและรับการประเมินที่เป็นรูปธรรม มิฉะนั้นคุณจะผิดพลาดมากกว่าถูกต้อง วิธีเดียวที่จะรู้ว่าสิ่งที่คุณต้องรู้คือการถามคำถามและคิดออกเอง

ระบบ CRM หลายคนใช้สิ่งที่เรียกว่าตอนนี้รูปแบบวัตถุ Expando ที่รู้จักกันก่อนหน้านี้เป็นรูปแบบสถานที่ให้บริการแบบไดนามิก มันเป็นพื้นสร้างพจนานุกรมคู่ค่าคีย์ ยกเว้นในกรณีพิเศษมาก ๆ ถือว่าเป็นการออกแบบ Anti-Pattern และควรหลีกเลี่ยง

ฉันได้ออกแบบและสร้างโซลูชัน CRM ที่กำหนดเองอย่างน้อย 8 รายการในช่วง 20 ปีที่ผ่านมาแต่ละคนและทุกคนมีข้อกำหนดที่แตกต่างกันและไม่มีโมเดลข้อมูล (ตรรกะหรือทางกายภาพ) ที่จะทำงานได้ทั่วทั้งกระดานสำหรับโดเมนทั้งหมด

โซลูชันเฉพาะสำหรับกรณีเฉพาะจะเป็นการออกแบบที่ดีกว่าเสมอ

มีเธรดใน DBA สแต็กเกี่ยวกับแนวปฏิบัติที่เหมาะสมที่สุดสำหรับฟิลด์บุคคลทั่วไปที่กล่าวถึงปัญหา มันสำคัญมากกับสิ่งที่คุณวางแผนที่จะทำกับข้อมูลและความละเอียดที่คุณต้องการ หากคุณต้องการสนับสนุนที่อยู่อีเมลที่ถูกต้องทั้งหมดหรือชื่อที่ถูกต้องทั้งหมดคอลัมน์ของคุณจะต้องมีขนาดใหญ่กว่าถ้าคุณเพียงต้องการสนับสนุนสิ่งที่องค์กรและแอปพลิเคชันของคุณพิจารณาว่าเป็นค่าที่เหมาะสม

ดังที่ Jarrod ชี้ให้เห็นถ้าคุณทำตามมาตรฐานทั่วไปคุณจะต้องจบลงด้วยรูปแบบการบันทึกที่มีหลายสิ่งหลายอย่างที่ระบบของคุณไม่จำเป็นต้องใช้ เนื่องจากคุณทราบอยู่แล้วว่าจะมีระเบียนจำนวนมากพอสมควรจึงเป็นไปได้ว่าคุณจะได้รับปัญหาเกี่ยวกับประสิทธิภาพที่ไม่จำเป็นเนื่องจากคุณสนับสนุนข้อมูลที่ไม่เคยใช้ ในทางกลับกันก็เป็นไปได้ว่ามาตรฐานจะไม่รวมเขตข้อมูลที่คุณต้องการซึ่งจะเป็นปัญหาที่เจ็บปวดในการแก้ไข ไม่ว่าคุณจะทำลายมาตรฐานโดยการเพิ่มเขตข้อมูลเหล่านี้หรือคุณจะต้องค้นหาวิธี (รวมถึง clunky) รวมถึงเขตข้อมูลที่ไม่ได้มาตรฐานภายในมาตรฐาน

ฉันคิดว่าปัญหาที่แท้จริงที่นี่ไม่ได้เกี่ยวกับการหามาตรฐานเดียวที่เหมาะกับทุกขนาด (ซึ่งมักจะเป็นหนึ่งขนาดพอดีกับ NONE) แต่คุณได้รับมอบหมายให้ประเมินโซลูชันที่ไม่ต้องการ ระบุไว้ ในกรณีเหล่านี้ฉันคิดว่าสิ่งที่เป็นมืออาชีพสิ่งเดียวที่ต้องทำคือการประเมินขั้นต่ำตามข้อกำหนดที่คุณมีและจากนั้นทำการประเมินสูงสุดตามข้อกำหนดที่ไม่ได้กำหนดที่เป็นไปได้ทั้งหมดที่คุณคิดว่าอาจเกิดขึ้น การประมาณการอาจหยาบและน่าขันซึ่งในกรณีนี้คุณควรอธิบายให้ใครก็ตามที่มอบหมายให้คุณทำเช่นนี้ว่ามันเป็นไปไม่ได้ที่จะทำการประเมินที่ดีจนกว่าข้อกำหนดจะมีความชัดเจนมากกว่า

มาตรฐานสากลที่มีอยู่

มีมาตรฐานค่อนข้างน้อย แต่มีเฉพาะในบางฟิลด์ที่มีข้อกำหนดที่แตกต่างกันสำหรับแต่ละฟิลด์ขึ้นอยู่กับความต้องการในการรวบรวมข้อมูล

ตัวอย่างเช่น แต่ไม่ จำกัด เพียง (และพูดคุยจากประสบการณ์กับทั้งสองสิ่งนี้):

• ซอฟต์แวร์จัดการกับข้อมูลผู้ป่วยและเวชระเบียนหากคุณวางแผนที่จะได้รับการรับรองตามข้อกำหนดบางประการ
  • มาตรฐานข้อมูลชุดเดียวกันสำหรับบันทึกข้อมูลเวชระเบียนผู้ป่วย ณ จุดดูแล (แสดงรายการมาตรฐานที่แตกต่างกันสำหรับเวชระเบียน)
• ทรอนิกส์เวชระเบียนและของพวกเขามาตรฐานทางเทคนิค

• ขอบเขตที่กว้างขึ้นของบันทึกสุขภาพอิเล็กทรอนิกส์และมาตรฐานทางเทคนิค

• ซอฟต์แวร์ที่จัดการกับบันทึกข้อมูลการโทรของผู้ให้บริการโทรศัพท์มือถือและบันทึกข้อมูลบริการ (ไม่ตรงตามมาตรฐาน แต่สำหรับการทำงานร่วมกันระหว่างเครือข่ายพันธมิตร)

ลิงก์ด้านบนบางส่วนไปยังเอกสารที่มีรายละเอียดพอสมควรแสดงรายการข้อกำหนดที่ต้องมีเพื่อสุขภาพและการจัดรูปแบบของฟิลด์ (เช่นHL7ใช้ประเภทข้อมูลที่กำหนดอย่างดี ) ที่มากของพวกเขาไม่ได้ไปในรายละเอียดมากว่านี้

มาตรฐานที่ผลักดันโดยรัฐบาลสำหรับการบันทึกภายใน

รัฐบาลระดับชาติหรือระดับท้องถิ่นมักมีความต้องการที่แข็งแกร่งในการบันทึกและจัดเก็บข้อมูลส่วนบุคคลสำหรับสำนักงานสาธารณะและเห็นได้ชัดว่าเกิดขึ้นกับ "มาตรฐาน" ของตัวเองซึ่งพวกเขาดำเนินการทั่วทั้งองค์กรของพวกเขา .

ตัวอย่างเช่นรูปแบบข้อมูลนี้สำหรับมาตรฐานบันทึกข้อมูลประจำตัวจากรัฐบาลนิวซีแลนด์

มาตรฐาน De-Facto ในซอฟต์แวร์

คุณสามารถรับแรงบันดาลใจจากสิ่งเหล่านี้หรือใช้แหล่งที่มาของซอฟต์แวร์ CRM โอเพ่นซอร์สที่รู้จักกันเพื่อใช้เป็นแนวทางปฏิบัติที่ดีที่สุดและแนวทางสำหรับข้อกำหนดข้อมูลของข้อมูลลูกค้าของคุณ

ดูรายการซอฟต์แวร์โอเพ่นซอร์สสำหรับธุรกิจและโซเชียล CRM 10 อันดับแรกซึ่งคุณสามารถค้นหาข้อมูลโมเดลได้ด้วยตนเอง

ผมว่าคุณต้องไปหามาตรฐานสำหรับระบบ EDI มีเอกสาร 'มาตรฐาน' หลายร้อยเอกสารดังนั้นคุณต้องเลือกเอกสารตามความต้องการของคุณ ตัวอย่างเช่นต่อไปนี้เป็นรูปแบบของใบแจ้งหนี้ TRADACOMSที่คุณสามารถคว้าฟิลด์ที่คุณต้องการ

เปิดโปรแกรมที่กลุ่มเผยแพร่ชุดของมาตรฐานเปิดสำหรับการดำเนินงานการประยุกต์ใช้และทำงานร่วมกัน พวกเขาส่วนใหญ่เป็นแบบ XML แต่พวกเขาระบุระเบียนลูกค้ามาตรฐานที่มีแต่ละฟิลด์และขนาด (มองหาCustomerPartyMasterในรายการมาตรฐานเอกสาร)

ฉันจะบอกว่า "คุณไม่ต้องการมัน (ยัง)" และกับ Ron Jeffries: "ใช้สิ่งต่าง ๆ เสมอเมื่อคุณต้องการสิ่งเหล่านี้จริง ๆ ไม่เคยมีเมื่อคุณคาดหวังว่าคุณต้องการมัน"

ดังนั้นถ้าถึงเวลาที่จะเพิ่มฐานข้อมูลที่เป็นรูปธรรมในโครงการคุณจะมีความรู้เกี่ยวกับข้อมูลที่จะถูกเก็บไว้ที่นั่นมากขึ้น