รักษาผู้ใช้และโปรไฟล์ผู้ใช้ในตารางที่แตกต่างกันอย่างไร

ฉันเห็นในสองโครงการที่นักพัฒนาต้องการเก็บข้อมูลผู้ใช้ที่จำเป็นในหนึ่งตาราง (อีเมล / เข้าสู่ระบบ, แฮชรหัสผ่าน, ชื่อหน้าจอ) และส่วนที่เหลือของโปรไฟล์ผู้ใช้ที่ไม่จำเป็นในอีก (วันที่สร้างประเทศ ฯลฯ ) โดยไม่จำเป็นฉันหมายถึงว่าข้อมูลนี้จำเป็นในบางครั้งเท่านั้น ผลประโยชน์ที่ชัดเจนคือถ้าคุณใช้ ORM ในการค้นหาฟิลด์ที่น้อยกว่าจะเห็นได้ชัดว่าดี แต่จากนั้นคุณสามารถแมปสองเอนทิตีลงในตารางเดียวกันและสิ่งนี้จะช่วยให้คุณไม่ต้องค้นหาสิ่งที่คุณไม่ต้องการ (ในขณะที่สะดวกกว่า) ไม่มีใครรู้ว่าประโยชน์อื่น ๆ ของการเก็บสิ่งเหล่านี้ในสองตาราง?

ขึ้นอยู่กับขนาดและข้อกำหนดของโครงการของคุณ

ฉันสามารถดูวิธีหนึ่งที่ข้อมูลเกี่ยวกับผู้ใช้สามารถแบ่งออกเป็นสองชุดโดยมีวัตถุประสงค์ที่แตกต่างกันและต้องการ:

• ข้อมูลประจำตัว: ชื่อผู้ใช้แฮรหัสผ่านที่อยู่อีเมลเวลาเข้าสู่ระบบล่าสุด ฯลฯ
• ข้อมูลโปรไฟล์ผู้ใช้ซึ่งรวมถึงค่ากำหนดของผู้ใช้กิจกรรมล่าสุดสถานะอัพเดท ฯลฯ

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

การตั้งค่าไม่จำเป็นต้องใช้ ACL เช่นนั้นและผู้ใช้หรือแอปพลิเคชั่นอื่นสามารถแก้ไขได้ในทางทฤษฎีตราบใดที่ผู้ใช้ยินยอม เงินเดิมพันต่ำหากแอปพลิเคชั่นประสงค์ร้ายหรือข้อผิดพลาดเกิดความเสียหายกับข้อมูลหรือพยายามที่จะแก้ไข (สมมติว่ามีมาตรการรักษาความปลอดภัยอื่น ๆ เกิดขึ้น) อย่างไรก็ตามโดยทั่วไปจะเป็นหายนะหากชื่อผู้ใช้รหัสผ่านหรืออีเมลใด ๆ เนื่องจากสามารถใช้เพื่อสันนิษฐานตัวตนของผู้ใช้หรือปฏิเสธบริการหรือทำให้เกิดค่าใช้จ่ายในการสนับสนุนเป็นต้นสำหรับผู้ดูแลระบบ

ดังนั้นโดยปกติข้อมูลจะถูกจัดเก็บในระบบสองประเภท:

• โดยทั่วไปข้อมูลผู้ใช้จะอยู่ในไดเรกทอรีหรือโซลูชัน IAM
• ข้อมูลการตั้งค่าจะสิ้นสุดในฐานข้อมูล

ในทางปฏิบัติผู้คนจะละเมิดกฎเหล่านี้และใช้อย่างใดอย่างหนึ่ง (เช่นเซิร์ฟเวอร์ SQL ที่อยู่เบื้องหลังผู้ให้บริการสมาชิก ASP.NET)

เมื่อข้อมูลเอกลักษณ์มีขนาดใหญ่ขึ้นหรือองค์กรที่ใช้ข้อมูลมีขนาดใหญ่ขึ้นปัญหาต่าง ๆ จะคืบคลานเข้ามาตัวอย่างเช่นในกรณีของไดเรกทอรีมันจะพยายามทำซ้ำการเปลี่ยนรหัสผ่านทันทีไปยังเซิร์ฟเวอร์ทั้งหมดในสภาพแวดล้อมที่มีหลายเซิร์ฟเวอร์ อย่างไรก็ตามการตั้งค่าของผู้ใช้เพียงต้องการความสอดคล้องในที่สุด (FYI: ทั้งสองอย่างนี้คือการปรับให้เหมาะสมที่สุดของทฤษฎีบท CAPS)

ในที่สุดไดเรกทอรี (โดยเฉพาะไดเรกทอรีออนไลน์ / คลาวด์) จะออกโทเค็นการเข้าถึงสำหรับทรัพยากรอื่น ๆ โดยใช้โปรโตคอลเช่น OAUTH (เช่นพิจารณา Facebook, Google, บัญชี Microsoft, ADFS) ในขณะที่ฐานข้อมูลไม่ต้องการเช่นนั้น ฐานข้อมูลจะสนับสนุนโครงสร้างการรวมที่ซับซ้อนและการสืบค้นซึ่งไดเรกทอรีไม่ต้องการ

สำหรับรายละเอียดเพิ่มเติมการค้นหาฐานข้อมูลไดเรกทอรีและฐานข้อมูลตัวตนเล็กน้อยจะช่วยได้

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

ถ้าคุณใช้ DB, IMO การใช้หนึ่ง DB กับสองจะทำให้การควบคุมการเข้าถึงทั้งในที่สุดสำหรับผู้ใช้และแอปพลิเคชัน

อย่างน้อยก็มีสามกรณีเมื่อมีตารางบุคคลสำหรับแอตทริบิวต์พื้นฐานและตารางที่สองสำหรับคุณลักษณะอื่นที่มีความสัมพันธ์แบบหนึ่งต่อหนึ่งเป็นสิ่งที่ต้องการ:

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

ฉันคิดว่ากรณีที่คุณเปิดเผยเหมาะสมภายในกรณีที่สอง

เหตุผลหลักของฉันในการแยกพวกเขาออกจากกันคือพยายามหลีกเลี่ยงสิ่งที่เป็นที่รู้จักในการเขียนโปรแกรม Object Oriented เป็น 'god class' ORM เชื่อมโยงตารางและฟิลด์เข้ากับคลาสและแอททริบิวต์ดังนั้นมันจึงมีความเกี่ยวข้องในระดับ SQL เช่นกัน (แม้ว่าจะไม่มี ORM ก็มีหลักการคล้ายกันในการเล่นทั่วไป)

คลาสผู้ใช้ (และโดยการเชื่อมโยงกับตารางผู้ใช้) มักจะเป็นตารางที่กลายเป็นคลาสพระเจ้าที่มีแอตทริบิวต์ / ฟิลด์หลายร้อยวิธีหลายสิบหรือหลายร้อยวิธีและคำจำกัดความของคลาส (สำหรับวิธีการ) มากกว่า 1,000 บรรทัด ฉันเห็นมันทั้งหมด มากกว่าหนึ่งครั้ง.

ดังนั้นการแยกออกจากผู้ใช้พยายามที่จะอยู่ที่ อาจมีบุคคลผู้ใช้บัญชีและการแยกข้อกังวลอาจดูเหมือนเป็นเรื่องเล็กน้อย แต่ก็คือพยายามและหลีกเลี่ยงความซับซ้อนและให้แน่ใจว่าแต่ละวัตถุเกี่ยวข้องเฉพาะกับ 1 ด้านของข้อมูลเท่านั้น